So coming from another post about the fringing on png alphas, I just noticed this other problem, which is hard to believe I haven’t spotted before…
The ‘reference’ image is from the VFB with a background layer baked in.
The exr output is basically the same with regard to the shadows (and correctly addresses the fringing thing as a bonus) but the png is totally wrong, being way too dark (and of course with the annoying matting issue).
Why is that?
Is it simply that a png cannot store the alpha of the shadows correctly?
All it is is the saved image and a white bkg layer.
From what I can see, it’s the exr being 32 bit that creates the correct (as vfb) transparency.
If I switch that to 16 bit in ps then it loses some of the transparency and matches the png version.
How are you saving to get a result which is the same?
Here’s the file…maybe you can spot what (if) I’m doing wrongly.
Probably something embarrassingly obvious MATTE DARK SHADOWS.rar (37.2 KB)
I might have confused the comparisons (I compared the 16bit .exr to the .png). When comparing a VFB applied white background to a .png with a background in PS, the PS version’s shadows are indeed darker. As my reply to the other topic, this difference is not present in Nuke, presuming the cause is PS’s method of interpreting .png transparency.
Yeah there is quite a confusing difference between different software.
As a test I opened both the 32 bit exr and png in PS, Fusion, AE and Gimp.
Photoshop is the only one that displayed the exr properly, with correct shadows and no fringing.
All the others got it variously wrong with the exr, either showing darker shadows and/or fringing.
With the png version, only Gimp displayed the shadows correctly but had the fringing issue, albeit a little better than the others.
So it seems that the only way to get a match to the vfb is to export a 32 bit exr and keep it as exr until final composite, as a switch to 16 bit will darken the shadows.
And then, it is only actually a 1:1 match if viewed specifically in photoshop or Nuke, which seems ridiculous to me.
I use AE rather than Nuke and in AE, as I found, it will not display the shadows correctly in the exr.
So the only option is either deal with incorrect shadows (for animation i.e.) or switch to Nuke.
Bizarre situation.
As an update to this, I just discovered that with the png, if I switch mode to 32 bit in PS then instantly it reads the alpha correctly, with remove black matte dealing with the fringing.
In AE I can use Set Matte to both regain the correct shadows and also to properly defringe, solving both issues.
So a good result overall and worth the time trying to solve it
Not sure what I’m looking at here tbh…did you try with the examples I attached in the post a bit further up?
The darker shadows I referred to were on a matte plane, which I ‘fixed’ by switching image mode from 8 bit to 32 bit, which seems an odd fix really, but it worked.
It’s late and I’ve had wine, so I will look at your suggestion again in the morning
Thanks! I was having hard time on this one! Change the blend mode in Color Settings worked in Photoshop. Now, my question is how my client will handle the file, because if he doesn’t make this change in Color Settings it won’t work. I’ve tried in Fusion to see how it handles the alpha and I’m having darker shadows as well. So, if I’m understanding this correctly, V-Ray saves alpha channel and RGB channels with different gamma settings. How can I make sure my client will have the correct shadow without messing around with Photoshop configuration?
In the attached image, on the left png straight out of VFB with a white background, and on the right png without bkg and alpha channel saved. The shadow is darker as it was in Photoshop
How should I deliver a png file with correct shadows to my client since he wants to use it in multiple backgrounds?
I think you’ll just need to tell the client that it’s a technical thing…that is, it’s not your fault lol.
Just get them to swap them to 16bit I guess is the only solution, unless anyone else has an idea.
I think the issue is generally that apps deal differently with something as seemingly obvious as the alpha channel, so we all
face this problem to various extents.
Thanks, not sure how I’m going to handle this scenario. Maybe sending the .exr in 32 bits and that’s it. You’ve mentioned 16 bits, but at least in my tests it only works in 32 bits or changing the blend mode in Color Settings. Is this a v-ray specific thing? I’m going to test using Arnold to see if it has the same behavior.
