display gamma in RT

I tried your suggestion changing max output to 2.2, switching to sRGB space and using adaptation in with linear color mapping. Although the results are close they aren’t exact, what settings did the beta testers use?

I was a beta tester and those are the setting I used. Not sure about the others, but they are unlikely to be all the same.

Not sure what would be causing any minor differences, but maybe make sure your VFB adjustments are all off (curves, exposure etc.) just to be safe. Also make sure you do not have “linear workflow” toggled on with that input gamma setting.

b

I’m not sure what this means but if I save out a rendered image from the VFB and do a print screen of the VrayRT window and open them both in Photoshop they are the same. However while I’m in 3D Studio looking at both the VFB and VrayRT windows the two images are different, the VrayRT image is much lighter.

These are the settings I use for LWF, and that do not give me problems with RT or cloning to the Max Frame Buffer:
- First image are the 3ds Max Gamma settings
- Second image is regular gamma settings for a brightly lit area, gamma at 1.0
- Third image is for renders with a lot of dark areas and shadows, gamma at 2.2 but with the “Don’t affect colors (adaptation only)”
- Fourth image is the VRay frame buffer with the sRGB button activated, a clone of the window to the Max frame buffer, and the V-Ray RT window




Sounds like you are getting double-gamma corrected in Max. Post a screen cap of your camera settings tab and your gamma preferences and maybe something will be obvious.

b

Here ya go.



Pretty subtle difference really - I thought it was more pronounced than that. Not sure that I would see that as a problem really. Am I missing something?

b

I guess there’s no point if we’re not concerned with accuracy, if VrayRT can’t produce a quick accurate result then that should be stated. I’ve been working under the assumption that it was capable of rendering the same colors, tones, hues, and saturation levels as Vray’s main engines. If this isn’t possible I’d like to know.

What are you using as your primary render engine? Brute force?

primary is IR secondary is LC

devin: I understood your issue to be one of matching framebuffers and gamma, not comparing the two rendering engines, so I’m sure your gamma stuff is fine. The differences you are showing there can probably be tightened up by matching your GI engines and some upping the tracing.

Not sure what Chaos Group’s position would be, but it’s probably worth remembering that this is billed as a *preview* engine, so differences are to be expected, and it seems obvious to me that *some* test renders and fine-tuning are to be expected - just fewer of them. If that RT preview is unacceptable for you then your margin on it is far tighter than mine, but it’s your call of course.

b

No I’m not saying it’s unacceptable I just wanted to know if the RT preview is supposed to match what is coming out of the VFB. If it’s not supposed to and there are going to be slight differences then I can accept that, I just want to be clear.

There are some comments regarding that in this thread:

http://www.chaosgroup.com/forums/vbulletin/showthread.php?t=45628

Posts #16 and #19

My experience so far has been that there can be slight differences, but it’s hard to predict in advance what they will be, other than that they are usually minor. I tend to run RT for a while and when I’m getting close to happy with a mat or light position (say 90% there) I run a quick Vray render to see how it stacks up and make sure I’m on target. If all is good I go back to RT. If not I may keep the difference in mind and continue with RT for a while anyway for speed, or at that point I switch to VRay to finalize. All depends on what I’m doing.

b

The differences you are seeing are because of the differences between the sRGB and gamma 2.2 color space. While both images are quite close in linear space, they are displayed differently in the V-Ray VFB and the 3ds Max ActiveShade window. The differences are typically most noticeable in the dark regions of an image.

Best regards,
Vlado

That’s good to know, thanks Vlado and everyone else I appreciate your help.

I’m pretty sure I use the same method as Steve and Devin. The point of this method is to ‘burn in’ LWF into the final image versus applying sRGB afterwards.

Gamma & LUT Preference settings:
1) Enable Gamma/Lut Correction.
2) Gamma 2.2
3) Affect Material Editor
4) Input Gamma: 2.2
5) Output Gamma: 1.0

Vray Settings:
1) Max FB: off
2) Vray FB: on
3) Dark Multiplier: 1.0
4) Bright Multiplier: 1.0
5) Gamma: 2.2
6) Affect Background: checked

Results:
1) The intended result is rendered directly in the VrayFB. This is LWF burned in.
2) This method does NOT using the sRGB button at all.
3) If you use the MaxFB, the image will be double-corrected using this method. Hence it is turned off.
4) ActiveShade preview looks ‘washed out.’ It is directly affected by Max Preference Gamma setting set to 2.2.

I am having the same problem as the original poster. The ActiveShade is much brighter/washed out then rendering to the VFB. In this example, I’m using a Vrayblend material. You can see that the sky is darker in the VFB, the ground is a slightly darker, and the carpaint is blown out.

I just threw together the scene quickly - didn’t really mess with camera and lighting settings.

Thats exactly right. This is the exact setup I have for the vrayFB. I dont use the maxFB and dont have to press the SRGB button as the gamma is burnt in. However, the vrayRT is definately producing a double gamma image. Could a gamma parameter be added to the vrayRT rollout ?

Yep, we’ll have to figure a way around this.

Best regards,
Vlado

However, the vrayRT is definately producing a double gamma image. Could a gamma parameter be added to the vrayRT rollout ?

I’m not sure if it’s quite double gamma. It seems very ‘close’ to double gamma. The reason I say that is because when I did hit the sRGB button, it was slightly brighter than the VrayRT preview.

If there was only some way to render ActiveShade within a VFB instead of MaxFB… (independent docking.)