Hi, so im yet again a little confused by the results in the VFB of the raw reflection and reflection gloss elements with regards to colorspace.
So I’m.using the default maya 2018 and its color management and im rendering with ‘dont affect colors, only adaptation’. With the display image in sRGB button ‘on’.
If im using a texture for the reflection, gloss and bump etc…do I either, need to have maya colorspace set to raw, or add the vray texture input gamma node and set to linear?
Also is the sRGB button not meant to affect these render elements?
The reason i ask is because I usually adjust my reflections/gloss maps using the remap node, and use the maya material viewer to visualise it, but when i render, the vfb render element doesnt match unless i add the texture input node.
(see screenshot)
First image is with no texture input node. (note how the vfb sRGB button is on)
VRay seems to differentiate between beauty elements (Lighting, Diffuse, etc) and utility elements (Reflection Glossiness, Raw Reflection Filter, zDepth, etc.) when choosing how to display them in the frame buffer. As it is, beauty elements are displayed with whatever settings you’ve enabled (sRGB, LUT, color corrections), but utility elements ignore those settings and are displayed in linear color, which will make them appear slightly too dark on your monitor. Don’t know why they chose to do it like this, maybe for color picking purposes? In any case, you need to disable the Maya color management (the sRGB button in the material viewer you were referring to) so it also displays it incorrectly, then they should match.
I’m not sure exactly what’s going on in your images, because that does look someone unexpected, but there could be a lot of other factors.
Try this, in a fresh scene leave all the VRay color mapping and Maya color management settings as default, then create a VRayUserColor (which is 50% linear grey by default, and plug it directly into the self-illumination and glossiness channels of a fresh VRayMtl, and then render that with Self-Illumination and Reflection Glossiness render elements enabled. The Self-Illumination pass should match what you see in the Material Viewer, but the Reflection Glossiness, being a utility element, should look slightly darker. Then in the Material viewer try toggling the sRGB on to off. Now the Material viewer should match the render elements.
You also need to disable color management in the color mixer to display the linear color values.
Note that the File node without any texture path set will ignore the Color Space settings and just use a default 50% grey value. But when you do load a texture, Color Space should match the color space of the texture file you’re using. Generally .exr = linear and jpg/png = sRGB.
I don’t actually know when you might use the the Texture Input Gamma attributes, maybe for special cases, or maybe it’s legacy. Seems to work fine without using that. I’m slightly confused about all this myself, so if I’m incorrect hopefully someone can correct me.
EDIT: I think it might actually be a bug that utility elements don’t get the color space, it’s just been like that for so long that I thought it was a feature. If I go back and forth between renders in the history while viewing a render element, sometimes it suddenly switches back to actually using the color space and corrections again. Or that itself might be the bug.
thanks for reply, yeah this was a fresh scene with a 50% grey jpg assigned to the diffuse, reflection and gloss. Yeah i can get them to match by turning off the sRGB in the material viewer as you mentioned…just seemed odd to have to do that.
Mostly what @dgruwier said with some notes: yes, V-Ray differentiates between channels that need corrections (beauty channels mostly) and channels that don’t (utilities and masks).
The VFB doesn’t follow the Maya Color management *output* settings, only the *inputs* (I’m almost sure, but again - need to double-check as I’m not in front of Maya atm).
In any case - I’ll be able to tell you more in the following days, I’ll make a note.
Cheers much appreciated. Im looking at it again, and I dont know if its meant to work how it is at the moment or not, but im just trying to make sure what i see is what im meant to see. If you look at the remap swatch, thats in sRBG, so you kind of adjust using that too..but the vfb doesnt match..so makes you wonder if you are over adjusting etc.
I should probably just ignore it and get on with the render, but I find the differences disconcerting
It would be correct for the rawReflectionFilter to *not* be affected by color spaces / corrections. It’s a raw mask actually. The reflectionFilter is a reflection mask affected by the fresnel falloff, and the rawReflectionFilter is a reflection mask unaffected by fresnel - that’s the difference and that’s why the raw mask shouldn’t be corrected. The raw mask will have a float value of the material reflection value at the given point.
The glossiness channels are also masks and they have float values representing the reflection glossiness at the point. They too should not be corrected.
As I understand it, monitors convert the display signal from gamma 2.2 to linear before displaying the output, which means that if you send it a raw linear, it will get get an extra 2.2 → linear conversion on top of it by the monitor as its converted to pixel voltages by the monitor, and will be incorrectly shown too dark. If it’s correct for regular images to be displayed in sRGB in the frame buffer, it should be correct for raw masks too, I don’t see why they would be any different. Even if they’re not affected by color correction and LUT settings, they should still at the very least still have a simple 2.2 gamma applied before being shown. I misunderstanding something here?
The reason was that after rendering, you would take those masks in a compositing app, where it mostly wouldn’t matter if they have corrections on top, but for some it may make a difference.
There’s still an option to force back the old behavior, using VRAY_VFB_COLOR_CORRECT_ALL=1 as an environment variable.
Its more than likely that im yet again confused by the mess of linear workflow, but I find it weird to me that the VFB works like that.
If i have the color mapping set to Gamma 2.2 and the mode ‘color mapping and gamma’ then i would expect all the elements to follow that, not just the beauty. Not to have it different, which just adds a level of confusion. If you want the render elements to be linear then surely you set the correct mode and then they all follow the same method?
Im not sure if i’ve been caught out with this being another issue and I could be getting confused thinking the discrepancy was in the vfb when it might be in fact, this issue instead…
Basically im getting different results when i render with vray, when i have a textures ‘alpha as luminance’ ticked on or off. Im pretty sure i reported this a while ago. Anyway to test you can either :-
1. Connect the alpha of a texture to the glossiness slot of a vray material and toggle the alpha is luminance.
2. Connect the alpha of a texture to a blendColor node and assign to any materials color (vray, lambert) etc.
If you render the last one with Maya software there is no difference between the 2, render with vray and there is…(see images)
ok so I think its the remap node too..I thought this had been fixed? Im having to put the remap through a gamma correct of 2.2 to get the look to match up. I dont even think the remap is working in Next either.
What type of texture do you connect there? Is it a procedural texture or a file node? If it’s a file node, what’s the format?
What are we looking at with the images? The beauty? A render element? Which one?
And what about the remap node - I didn’t get this part at all.
Sorry was getting a little exasperated as im sure i posted about the issues with the remap before…anyyyyway..
So firstly. Ive added the VRAY_VFB_COLOR_CORRECT_ALL=1 to my maya.env file.
Secondly I’ve attached a scene.
So I have a 50% grey JPG mapped to the glossiness slot of a vraymtl. The first image is the glossiness render element when the ‘alpha is luminance’ is off, the second is when its on.
Also, if you use the remap function in the texture node, regardless of the ‘alpha is luminance’ setting you get the same as the second image. To clarify, my point with the previous post, was that if you render in maya software, the images seem to be fine. (i used the blendcolor to allow me to use the alpha channel of texture only)
So im just trying to figure out if this is whats expected to happen?
Can I propose a middle ground? Displaying images with incorrect gamma in the frame buffer doesn’t benefit anyone, and users shouldn’t be mixing linear and color corrected footage like this in any case.
…But displaying utility passes with artistic color corrections like exposure and hue/saturation is not correct either. If I change the exposure of the beauty, I don’t want to see the rawReflectionPass become brighter.
So how about displaying all utility passes in the viewport in sRGB, but without color corrections? That way you see your utility passes displayed correctly on the monitor, but they’re still “raw” and untouched by anything that goes on in the color correction panel of the frame buffer. And if you still want users to be able to mix it up when saving the files, add a “save utility passes without color correction” checkbox in the save file dialog.
The image is indeed 0.5 grey, but there’s an sRGB correction on top of it in the maya file node, making it darker. The gloss channel reads 0.25-ish as expected. With sRGB applied in the VFB it should be correct in this setup.
The gloss channel receives the outAlpha, and here’s where things get a bit strange. Since it’s a jpg, there’s no alpha and Maya is somehow calculating the alpha (I don’t know how) when ‘alpha is luminance’ is off. When it’s on, it’s all good.
Meaning that the correct setup should be raw color space in the file node, when sRGB is disabled in the VFB, or sRGB in the file node when sRGB in the VFB is enabled. It might be that maya software is automatically doing alpha as luminance with jpg.outAlpha.
Thanks I appreciate your help, is this what people are doing because it just seems a bizarre workflow. Eitherway im not convinced its working correctly and it definitely seems im back in the linear workflow hole of confusion again…arrghhhhh
At the moment, without that environment variable enabled, utility passes are unaffected by the sRGB toggle, and appear too dark in the frame buffer. Maybe a bug or problem with how it’s implemented, if the intention already is to have the utility passes still have sRGB (but ignore the color corrections) when the environment variable is disabled?
To be clear, by color corrections I mean everything in the “corrections control” panel, excluding the “Display colors in sRGB” toggle.
I guess it’s a complex issue. I’d prefer utility passes to be shown in sRGB, but ignore color corrections, and my colleague prefers showing them with color corrections. Maybe it’d be helpful to get input from more power users. In any case, let us know what you work out
