How do I put a backplate that isn't affected by color mapping & color corrections?

[Alex_M]

I'm not too concerned that VFB doesn't save the loaded backgrounds. I can easily copy the rendered image to the clipboard and paste it wherever I need and the background will carry over fine. What I'm concerned about is that the background is affected by the sRGB button at the bottom. I don't do the sRGB correction from this button so the background image becomes dark. And also the bad aliasing/no filtering, that's a problem too...

There's no solution to these problems at the moment?

[^Lele^]

Well, yes, the behaviour is expected, the button on the VFB is the view sRGB, not the sampler's internal color mapping one.
In essence the two operations are applied at different times (one before light transport is evaluated, the other when the games are done, on the pixels of the rendered image), and produce very different results (well, not the sRGB alone, in this case, but non-linear mapping in general.).
Think of it this way, if i oversimplify it a bit for argument's sake:
Say you apply a gain of 2.0 to the internal color mapping, by whichever means (say, halving or doubling bright and dark multipliers, and so on.), that will double the intensity of the distributed light as well, double the diffuse level of the surfaces, their reflectivity, and so on, in essence skewing light transport, and baking it into the rendered image (which is where ultimately you see the results of the CM skewing.), and in this case the net result will be a strong lowering of the light distribution's contrast, along with a substantial brightening of the render.
Now, say you apply the same gain at the VFB stage, or in other words after the (expectedtly) radiometrically linear light transport equation has been resolved, now you cannot in fact touch the GI separately, or the diffuse, from the beauty RGB alone (Cue REs and post. but we said no to all that, right?).
This means that the light will have fallen off correctly during the calculations, on the right albedo shaders, and then had been multiplied as an image operation afterwards, the contrast of the solution unaffected.

EDIT: as a corollary to their order, and very different operations, the view color mapping (all of the controls, including the sRGB button) are live, and directly undoable. Any of the internal color mappings will require a re-render to be applied to the scene's values interpretation before they're fed to the rest of the process.

Of course, if people like to depart from LWF, they can do so.
I agree on the fact the only solution for such cases may be a CM lineariser.
And of course have zero opinion on the feasibility or necessity of it (not my role.).
It's surely the first time i hear such obstinate need to do an A-Over-B IN the VFB, with non-linear CC to the scene but not the plate, instead of using an alpha channel and any of the free compositing or painting tools (gimp, if that's what it took me.).
I simply can't fathom why i'd lock myself into said linearised BG at the price of a rerender for each minor correction: i'd rather prefer a different sort of torture, like solitary confinement... ^^

[Alex_M]

I stopped using the sRGB button, now I use curves/exposure to simulate the sRGB curve instead. I find that I have a much better control over colors with the CC tools in VFB when I'm not using that button. When I use it and make any corrections, the colors get destroyed pretty fast. It's got something to do with the particular order of CC operations from what I understand. You can check this thread I started some time ago regarding this problem: http://forums.chaosgroup.com/showthr...or-corrections

Attached are some screenshots which show how colors get completely wonky (image 3) when using the sRGB button and how much more natural colors look when doing color corrections without using the sRGB button (image 2). I still have Max and Material Editor in Gamma 2.2 space, I just don't use the sRGB button. Which image looks better to you, 2 or 3?

[thanulee]

Thing tend to over complicate really quickly in vray posts
Another solution: Use the bg image for viewing purposes, do ur vfb corrections, save with alpha, replace bg in photoshop with no edges problem whatsoever. That shouldnt take u more than 20 seconds for real

[LudvikKoutny]

I'm not too concerned that VFB doesn't save the loaded backgrounds. I can easily copy the rendered image to the clipboard and paste it wherever I need and the background will carry over fine. What I'm concerned about is that the background is affected by the sRGB button at the bottom. I don't do the sRGB correction from this button so the background image becomes dark. And also the bad aliasing/no filtering, that's a problem too...

There's no solution to these problems at the moment?

Well, that's odd then. If you don't do sRGB correction in VFB then you are most likely doing LWF wrong. And that can even cost you rendering performance, since V-Ray may be sampling different colorspace then one you are viewing, and you may get a lot more noise. I mean, that button should not even be there. It should be always enabled and hidden

[Alex_M]

Well, that's odd then. If you don't do sRGB correction in VFB then you are most likely doing LWF wrong. And that can even cost you rendering performance, since V-Ray may be sampling different colorspace then one you are viewing, and you may get a lot more noise. I mean, that button should not even be there. It should be always enabled and hidden

As far as I know that button has nothing to do with how the sampler sees the scene, it's there just for previewing purposes. How the sampler sees the scene is controlled by the "Gamma" setting in Color Mapping. Someone correct me if I'm wrong.

[thanulee]

Well, that's odd then. If you don't do sRGB correction in VFB then you are most likely doing LWF wrong. And that can even cost you rendering performance, since V-Ray may be sampling different colorspace then one you are viewing, and you may get a lot more noise. I mean, that button should not even be there. It should be always enabled and hidden

Yes. Alex, u shouldnt approach it this way. Ofc u can add gamma 2.2 in post (or vfb) but there is a strong reason u shouldnt do that.
Probably u know all about LWF, but in any case check this out for further clarification : http://www.aversis.be/tutorials/vray...orkflow_01.htm and this https://www.youtube.com/watch?v=iSwnXjADO9U

As recon said, at some point SRGB button should be hidden and enabled for avoiding further confusion to users.

[LudvikKoutny]

As far as I know that button has nothing to do with how the sampler sees the scene, it's there just for previewing purposes. How the sampler sees the scene is controlled by the "Gamma" setting in Color Mapping. Someone correct me if I'm wrong.

Yes, and it should be set to color mapping only. And if you do have it correctly set to color mapping only, then your image must be very dark in VFB unless you have sRGB button enabled.

If you do not have sRGB button enabled, and you are manually doing sRGB curve with VrayVFB curves, then you are baking sRGB into output, which you can do simply by having 3ds Max bitmap output gamma set up correctly.

I don't see point of this workflow aside from making things unnecessarily more complicated and error-prone.

[Alex_M]

I don't see point of this workflow aside from making things unnecessarily more complicated and error-prone.

You are right, it's more error-prone but I really don't like how color corrections behave in VFB when I use the sRGB button. I'm getting very weird/distorted colors this way when I want to make color corrections... Almost like posterization effect, especially in the darker tones.

[LudvikKoutny]

You are right, it's more error-prone but I really don't like how color corrections behave in VFB when I use the sRGB button. I'm getting very weird/distorted colors this way when I want to make color corrections... Almost like posterization effect, especially in the darker tones.

Hmmm, that sounds more like insufficient bit depth than a colorspace problem. Are we talking about color corrections in VFB or outside, when you save the image?

[Alex_M]

Hmmm, that sounds more like insufficient bit depth than a colorspace problem. Are we talking about color corrections in VFB or outside, when you save the image?

Inside VFB. Did you see the screenshots in reply #18? It's a snapshot of VFB. You see the posterization there, especially in the darker tones, don't you? Colors don't seem to shift smoothly.