The question is partially general and partially Krakatoa-specific.
In Render Elements I can’t seem to find separate alpha channel layer for export.
Probably I could live with this since I can export to any format supporting alpha and one can argue external alpha channel is redundant.
The problem I have is that regardless of how I treat alpha channel in post I can’t seem to get results comparable to what I see on the max render screen.
To be a bit more specific:
I am rendering a pointcloud with lots of transparencies (20-50M points on 2K frame w/ motion blur, DOF).
My environment is black, no objects, no bitmaps, no fancy stuff.
I am saving either to high bit depth TIFF or PNG w/ alpha channel
rendering looks good when previewed against black background in Max/Krakatoa render window
When I import stills to Adobe AE or Premiere and use alpha channel then place the layer on top of black background I can’t get any close to the appearance I had in max, no matter if I use Straight or premultiplied. It looks like the object is barely visible.
If I ignore Alpha it looks good though (identical to Max previews)
to gen any results that make sense I need to duplicate the layer like about 20-50 times to have it comparable with results in max (or manipulate alpha channel very aggressively with curves).
Did I miss something obvious?
Any help is more than welcome.
RGBA TIFF Imported to AE + Premultiplied Alpha against black background = very dark and weak look
Further investigation via opening the file in Photoshop and examining alpha channel shows that for some reason Alpha channel looks somehow different to what I have in RGB content.
Some areas where I have lots of information in RGB look black in Alpha. I understand the opposite, but can hardly understand that.
Are there any known issues or a behavior of Krakatoa that might cause this effect?
There was a discussion on the Krakatoa thread on CG-Talk about this and the consensus was that Adobe was handling something differently when it comes to premultiplied Alpha, but I am not sure what that could be. There have never been any problems between Krakatoa and the compositing apps used in the VFX industry (Nuke or Fusion). I suspect that you are a much more advanced user of AE and if you cannot figure it out, I might not be able to help since I have never used AE for anything (or seen anyone use it in production at our previous company in the last 5 years).
Using an older AE version, someone having problems with Alpha posted this: forums.cgsociety.org/showpost.ph … count=1409
But others using the current AE version commented that this did not solve their problem, and it sounds like you have hitting the same issue.
Some general comments:
*Krakatoa should be used to save to OpenEXR. Period. Krakatoa generates floating point RGBA data beyond the 0.0-1.0 range, and most other file formats would potentially clamp that data. But from what I know, Adobe does not handle EXR much better than everything else, in fact I hear it might be worse.
*Max has the option to save TGA with split Alpha and optionally unpremultiplied RGB. It would be interesting to try that and see if it makes any difference (my guess would be no).
*Alpha in Krakatoa is product of the Volumetric shading. Under certain circumstances, the Alpha can go down to 0.0 if the volumetric shading channels contain data that would produce additive rendering (fully emissive rendering with black color and absorption). I don’t think this applies here, but it could depending on the settings. This is explained in thinkboxsoftware.com/krak-mi … and-volum/
Thanks Bobo.
I am not sure if that’s the matter of AE particularly because I opened both TIFs and PNGs in Photoshop and examined Alpha (as shown in the example above).
And clearly there is something wrong with the alpha channel itself that is a separate issue from the interpretation of alpha in AE for example.
I am not using Force additive
I am using emission and lighting
I am not using absorbtion
Look at the pillars for example - the group in top right shows the issue clearly - RGB shows the entire pillar body whereas alpha is almost all black there. Same on walls - there are some black stripes in alpha on the walls which are not visible on RGB.
I would not think it is related to the format you’re saving to (and same issues are with PNG and TIFF).
I think there must be something in KRK that makes this look like that.
What version are you running right now? 2.1.4?
Try rendering in build 2.0.2 if you are not using Max 2013. Just in case. 2.0.2 is the official release of Krakatoa MX 2.
If they all render the same, then there is something in your setup that is producing that result. I guess that if there was something generally wrong with Krakatoa’s output, it would have been reported years ago.
Do you get the same Alpha look if you render without any lights and no motion blur and DOF? This would generate black RGB and only Alpha from the particles. Also disable all Magma operators that manipulate the color, density, culling etc. See if rendering the pure PRT Loader without any post processing of the data and without any lighting produces a different Alpha channel. It is quite possible that something in your setup is causing a strange behavior.
If you can, use OpenEXR. In all the years in production, we haven’t used anything else for image output, ever.
If you can think of a way to pass to me some data to play with here (via FTP or whatever) as long as it is under a GB, I would be interested in testing things on my side…
I don’t think there’s a serious difference in how the alpha is handled between the different filetypes.
However, apparently there’s a huge difference between what’s being saved to file (any type) and what’s visible in MAX Render window.
I attach screen grabs from Max and a bunch of saves.
These files were rendered same way as previously described.
Did not have time yet to perform magma vs pure loader data tests as you recommended.
BTW, Looks like openEXR is tough to handle for Adobe apps - at its best it can read alpha channel, but any other channels seems inaccessible out of the box at least.
I don’t think I want to jump into serious compositing software for this project since my only goal was to render and tweak stills a bit, edit and send to color correction.
So I am using AE mainly to combine stills into ProRes4444 which is my editing codec of choice.
I am on a 3DMAX 2012 x64. Krakatoa - not sure now as the render is going there, but I think its a few builds before the latest 2.1.3 (we discussed that in another post earlier).
Ok, I loaded the file S1-M6-V002_00103.exr back into Max.
My Max is set to Gamma 1.0 and I got the DARK version you are getting in your other applications.
When I enabled the Gamma 2.2 in the Customize > Preferences > Gamma tab, the display matches your Max screenshots.
Note that Krakatoa does NOT apply the Gamma of 2.2 when saving the files, they are effectively all 1.0 Gamma when saved.
This explains the huge difference you are seeing between the Max frame buffer and what is loaded into other applications.
So you should either tweak the rendering at Gamma 1.0 to get what you would expect, or apply Gamma 2.2 to your input images when loading them into AE and hope the Alpha will also be affected (I don’t think it should be, but Max does it anyway).
I would suggest the former approach. In general, your Density is too low and Max is just making it appear higher because it is color correcting its display in the VFB.
Here is what the Max help says about the Gamma Pipeline: docs.autodesk.com/3DSMAX/15/ENU/ … E81ED5.htm
In short: When outputting to EXR (HDR which Krakatoa generates and should never be clamped or gamma-corrected), use Gamma 1.0.
I have to check with the developers, but since Krakatoa is supposed to always output HDR content, I suspect they have overridden the Gamma settings of Max to always output 1.0 regardless of what the Bitmap Output settings are. Hence the confusion. We will have to clarify this in the documentation.
OK, looks like we spotted the issue, however I am not sure if fully.
Can you resent the link or describe how to find the gamma pipeline help? I can’t seem to find it (link is broken and sends me to the index).
What do you exactly mean that you have your max set to gamma 1.0? I have Gamma and LUT tab in my Max and there I have:
–> Enable gamma/lut correction checkbox
–> Display group with gamma set to 2.2
–> Bitmap files group with input and output gamma set to 2.2
How should I set it up for work with Krakatoa and your recommended workflow?
There are still some things that puzzle me regarding relation of Alpha to RGB.
I don’t use any density modifiers in my Magma Flow and it’s not availalbe in the file. Everything is density 1.0
My Magma operates only on color and emission plus I have scene lighting
when I render a frame and examine it in VFB I see (sorrect RGB) but alpha for some very bright pixels is very low (and it’s reflected after saving)
See attached screens - good example is bright vertical area to the right.
Looking at the rightclick data available in VFB (before any corrections) RGB values are around 0.5-0.75 but alpha for these pixels is around 0.01 - 0.03!
What I was trying to say is that since Krakatoa is HDR, I have Gamma DISABLED in the Gamma & LUT Tab. This in turn uses gamma of 1.0 throughout the pipeline.
So if your Gamma is turned on and set to default 2.2, it will show you skewed Alpha information visually in the VFB, but right-clicking on a pixel will show you the actual data around 0.03 or even less…
The Alpha produced by Krakatoa is based on the Final Pass Density. Since your Lighting Pass Density is two orders of magnitude higher, your Lights are seeing the particles as 5.0E-3 (0.005), while the Camera is seeing the particles as 5.0E-5 (0.00005). So when you accumulate multiple particles into a pixel, all you get is a very low density (very ghost-like rendering), but the lighting looks bright and happy with nice shadows because the density is set to be 100 times higher for the lighting pass!
The problem with the Gamma of 2.2 is that
The Max VFB displays the Alpha as much higher than it really is, thus confusing you and giving you wrong expectations what the actual saved data will look like
Krakatoa does not apply any Gamma when saving its images because it adheres to the HDR pipeline, so what you get in the saved files has the real unmodified values.
I would suggest disabling the Gamma & LUT in Preferences and trying to increase the Final Pass Density multiplier to 5.0E-3 or even higher until you get the Alpha you want.
Thanks for explanations. It all starts to be clearer for me.
Few more clarifications:
Do you mean that Max VFB shows gamma as much higher only at non-1.0 gammas or it would confuse me even if I am looking at it with 1.0 Gamma settings?
While working with open-EXR files and Gamma 1.0 linear space and saving to 32bpp floating point - should I get all values below 1.0 for RGBA in VFB prior to saving? Or I am safe with higher values?
I assume that while saving to 16bpp if something is above 1.0 / 65535 it will be clipped?
Assuming I go for 32bpp floating point, 1.0 gamma and open-EXR workflow, what figures should I target out of my magma flows in relation to color and emission? should I adhere to [0-1] or [0-255]? Or anything else?
Different lighting pass was something I did deliberately since it gave mee good look in VFB. I wasn’t aware of the fact that alpha is based on the other setting.
I am tweaking all my settings to get good alpha and good look. One question though - I did 100 higher lighting pass because it somehow gave me good and visible self-shadow casting on a relatively sparse pointcloud.
Now it looks I need to be very close if not equal for both passes. How can I tweak other settings to get ‘exaggerated’ shadows cast by the pointcloud on itself?
Last question - I understand color and emission do not affect alpha at all?
Max VFB shows the settings of the Gamma & LUT tab. If you disable Gamma there, it will be showing the data with 1.0 Gamma. The reason to use Gamma of 2.2 is because monitors don’t have linear color reproduction and using Gamma of 2.2 is supposed to show to the eye what, say, a photograph taken in the real world really looks like on other devices, e.g. print, calibrated video monitors, TV etc.
But you were judging the ability of your image to composite with other images by looking at the skewed gamma-corrected Alpha values which appeared brighter in the VFB than they really were in the file. Thus the confusion.
EXR is by default set to 16 bit floating point (half-float). It is still HDR and can express colors above 1.0 without problems. While the Max VFB at 16bpp INTEGER shows you 1.0/65535 for a pixel, EXR will actually save a floating point number. If you had a pixel value of 2.0, 32.1 or 124.5, these would appear as white in the MAX VFB because it cannot display higher values on screen, but the EXR file would actually contain the real floating point numbers, just with a lower precision than 32 bit. So I suggest you keep the EXR saving at 16 bit float and render whatever looks good to you. Chances are you won’t have many values above 1.0, but if you do, they will survive the saving and you will be able to color correct them in post. Having seen your Making Of videos, I am sure you know what you are doing when it comes to HDR imagery
I don’t think you need to change much in the lighting settings. What you are trying to do now is get the camera to see what the lights are already seeing.
Typically, when working in Krakatoa, we have the Lighting Pass Density set about 1/5 to 1/10th of the Final Pass Density to let more light pass through a solid object. So if the FPD was 5.0E-3, the LPD would be 1.0E-3 or 4.0E-4. But this is the case for solid-looking clouds (see our examples in the Krakatoa for Maya docs here: thinkboxsoftware.com/kmy-ren … rt-volume/
As far as I understand, you do want a ghost-like appearance of your clouds in the final image. So having the Lighting Pass Density higher than the Final Pass Density might just be the way to go. We are just trying to give you a slightly more solid-looking Alpha, otherwise compositing the result over black or anything will give you very little color. On the other hand, it might be enough to just tweak the Alpha in post to boost it without changing the Krakatoa render settings - the Alpha is floating point too, so you should have enough data there to get the look you want without fiddling with the Krakatoa side of things too much.
Emission is currently just a value that gets added to the Lighting of the particle without a specific source. So it is the particle’s own light coming from the particle itself. This does not affect the Alpha, but it is affected by the Density of the particle (or the optional Emission Scale control that can be decoupled from the Density).
The Color is actually the “Scatter” component of the volumetric lighting equation, it describes what part of the color of the light will be bounced back into the eye (or when rendering in Isotropic mode, in all directions equally). Now the funny thing is (as I posted previously via a link) that if there is no Scatter color (it is black), then no light would bounce back into the eye. And if the Absorption is also black, then nothing gets absorbed, nothing gets scattered, and there would be no Alpha, because no light would be bounced back into the camera and the camera will see nothing. Dark Matter! And if you add Emission to the particles, all you will see is the Emission color coming directly and adding in the pixels without any interaction with light and shadows, thus producing the Additive rendering. As you can see on the images posted in the “Mixing Volumetric and Additive Rendering” topic, as the Color and Absorption approach black, the Alpha also approaches 0.0, so in that case the Color DOES affect the Alpha But since you are not using the Absorption channel and overrides, it does not.
Assuming I go for 16 or 32bpp floating point, 1.0 gamma and open-EXR workflow, what figures should I target out of my magma flows for color and emission? should I adhere to [0-1] or [0-255]? Or anything else?
Under the hood, Max works in the [0-1] range, but it represents the data in the UI in the [0-255] range, except in mental ray shaders where it switches the color picker to a special Point4 mode that uses [0-1] and has an Alpha channel.
Magma also assumes that colors are expressed in the [0-1] range. The color swatches and the RGB values (X,Y,Z) in the InputValue Vector node are all in the 0.0 to 1.0 range. But the global overrides in the Krakatoa UI are in the 0-255 range (except for the Background color which uses the Point4 mode since it needs to provide an Alpha channel).
So you should use the controls as they come - in Krakatoa, they end up being the same. For example, a Global Color Override of 255,0,0 is the same as a Global Channel Override with a MagmaFlow (InputValue [1,0,0]) --> (Output Color). Both will override the color to Red.
Note that the 0-1 range color picker also lets you enter values > 1.0 (for HDR data), while the 0-255 color picker does not. But in the end, both represent the same data, the one is just more limiting.
But since you are not using the Absorption channel and overrides, it does not.