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

[Alex_M]

I’m trying to integrate some stuff into a photo. How do I put a backplate that isn’t affected by color corrections and color mapping? This is really easy with Corona, you just use the CoronaOutput map - https://coronarenderer.freshdesk.com/support/solutions/articles/5000522247-how-to-create-a-texture-which-is-not-affected-by-color-mapping- Sorry for the long link, I’m on a proxy because I can’t access the forums and the formatting bar at the top is gone.

How do I achieve this with Vray? I don’t want to use the “Background Image” functionality in VFB because it’s causing nasty artifacts around the edges of objects and it also doesn’t work with my workflow - I’m not using the sRGB button and the background image becomes dark if I disable the sRGB button.

The only workaround I found so far is to use a bitmap with screen mapping in the Environment slot and then I spend time adjusting it in an Output map with IPR until I sort of match it to the original photo which I have open on my 2nd monitor.

Yea, it’s a pain and I’ve got the feeling that I’m missing something very simple. I’ll admit it, sometimes I am stupid enough to miss something that’s been in front of my eyes all along. Any ideas on the “button” or the “map” that I’m missing? Thanks in advance!

[Alex_M]

Sorry, I forgot to add some images but the proxy won’t allow me to edit my posts so I’m forced to add new replies. I should be twice as careful with my posts from now on…

Using the “Background Image” function:

Original photo:

How it looks when I don’t use “Background Image” but the Environment slot instead. It sort of works but it’s not ideal and takes more time to get right than I would like:

[thanulee]

If i understood correctly, maybe affect background off in color mapping is what u want? cheers

[Alex_M]

@thanulee

If i understood correctly, maybe affect background off in color mapping is what u want? cheers

Thanks for the suggestion, it does sound like the logical solution but the fact is it still doesn’t work. Even if I have it turned on, all color corrections in VFB (exposure, curves, etc) affect the background. In Corona with the CoronaOutput map even if you make adjustments to exposure, curves, color balance etc. the background image doesn’t change one bit.

[thanulee]

Well it does work, i mean color mapping doesnt affect ur bg. But yea, vfb is logical to affect ur bg image since its like doing it in post. I d suggest to dont use vfb corrections and do those stuff in post. Finer control anyways, and if u just use those controls wont take u more than few minutes to set em up in post. cheers

[Alex_M]

That’s certainly a solution but not really for me because I want to do changes to the scene interactively while rendering with IPR and I need to know how the objects look in the context of the backplate while setting up the scene. It would really break my flow to jump from one environment to another constantly. I hate having to switch to other software for simple projects like this when it should be easy enough to do right in Max/Vray. I just need the backplate to not get affected, that’s all. There must be a way. I checked all maps in the help pages and it seems that none works like corona’s CoronaOutput map. I also checked for any sneaky button I might have missed in VFB or in Render Setup but I didn’t find one either. Don’t tell me I should switch to corona for these types of jobs.

I feel like the “Background Image” option in VFB is the thing I’m looking for but if this is really the analog of CoronaOutput map in Vray then I think it needs some looking at because it doesn’t really work for me. 1st, when I turn sRGB off, the background image is affected too and I don’t want it to since I don’t use sRGB corrections in VFB, I simulate it with the curves and exposure. 2nd, for some reason using curves cause white halos around the objects. And last but not least, the background image is pixelated which is undesirable. Attached is a screenshots showing the halo and pixelation problems:

[thanulee]

Yes Alex i get what u mean.
In situations like these personally, i change my lights in order to blend things better. And that is the logical way to do this if u wanna composite objects and not try to match em mostly in post. Post should always be complementary. If we talking a sky here, or a window opening it can completely done in post/vfb, but if we talking about proper compositing on a backplate from a shooting, u shouldnt do this through vfb adjustments.
Maybe ask the support for a better implementation of the background image in vfb if that fits ur specific needs better. have a nice day!

[_Lele]

Alpha Channel?

[Alex_M]

@_Lele

Alpha Channel?

I’m not following you, can you elaborate?

[_Lele]

sure, here.

Notice how exposure affects the render, not the BG.

[_Lele]

oh, you want an inverse CM map, i see.
Nevermind my previous replies, i read further down the thread when the objective was a bit more muddled, EDIT: and i got your question wrong. Also, i was writing this while you replied.
it shouldn’t be terribly hard to implement in principle, but i’m not the one to know, yet it still wouldn’t save you from any VFB corrections you’d apply after the render, hence me saying save your alpha channel, and do a proper composite, if it’s a backplate you need.
If you have edges you’re likely doing something wrong on the comping side, or whacking both RGB and alpha so out of the original range that edges will come up and will have to be dealt with. Proper (un)pre-multiplication and separate channel work has been proven to work for many decades now.
If you end up with fringes, then you’re likely asking too much of the rendered data (ie. too much brightening or darkening), but that only becomes apparent after a couple of stops either way of the rendered result.

See the attached Contactsheet (download is likely needed.).

EDIT: While inversing the CM for a given bitmap is surely doable (that’s in essence what a vrayLUT or vrayICC do, given a forward descriptor), as i said you are then bound to whatever you will apply to the VFB.
Any “automated” implementation of the composite work i showed above inside the VFB (ie. separate BG controls, saving it with the render, and so on) would *not* sidestep the issue with the contrast gradient on semi-transparent edges being steepened by different CM applied to foreground and BG.
That is why one uses a post app: to have the tools to afford latitudes which require more severe alteration of the input data (ie, alpha work, edge recovery, and so on and so forth), where the tech at the avail simply can’t achieve a satisfying (albeit correct, mathematically!) result for the specific needs.

[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/showthread.php?91561-A-question-about-VFB-and-color-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

[Alex_M]

@Recon442

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]

@Recon442

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/vray-20-gamma-linear-workflow\_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.

[Alex_M]

@Recon442

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.

[Alex_M]

@Recon442

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.