I’m getting an error when I create the diffuse light pass by multiplying the rawLight with the diffuse color:
X
As you can see I get a bright line along the edge of my character that does not appear in the beauty (especially obvious on the bottom left edge):
I am rendering this in exr linear using all vray lights (2 sphere, 1 rectangular).
If you zoom into the images, you can see that the rawLight character is a few pixels smaller than in the diffuse pass which is causing the bright edge. Because of the background the alpha is pure white, which rules out a pre-mult error on the alpha, but it looks like there is something like that going on with the rawLight and diffuse not lining up.
The error is pretty simple to replicate with a sphere and single light. This is a close-up of the beauty pass. Notice the edge of the ball in the shadow area:
Now here is the result of multiplying the Diffuse and RawLight. Here in the shadow area you can see a 1 pixel red line. This is the error, which comes because the Diffuse and RawLight passes are apparently off by 1 pixel:
Nuke.
But the error appears in any comp software, including Photoshop and After Effects because there is a 1 pixel difference between the diffuse and rawLight (seen the images in the first post)
I discovered the exact same issue. Is this solved by anyone? One way to solve it might be to blend the lighting pass and the diffuse using the divide operation to recreate the RAW light channel without the discussed artefacts.
After studying your image, I believe the problem may be the result of anti-aliassing and multiplication. Does your raw-light pass really have that bright background like in your first example?
This kind of artifact (it’s not really an error) is likely to happen whenever you multiply passes; unfortunately is not easy to avoid. One way is to render larger images, do the compositing, and then downsample the result. Another option will be to use deep compositing, whenever that becomes available.
V-Ray already computes all the necessary info, but there is currently no standard format to write it to. In 3ds Max one can use the RPF format to some extent to store the deep pixel data. There is some talk that OpenEXR 2.0 will also support it, but it is not available yet. Currently we have our own deep pixel .vrst format that we use for the shade maps in the V-Ray stereoscopic helper, and we will attempt to write a plugin for Nuke that reads these files whenever the new version with the deep pixel API is released. So yes, we are working on this
