Forum Moderators: wheatpenny, TheBryster
Vue F.A.Q (Last Updated: 2024 Dec 13 6:58 am)
The scene is the simplest possible, but also I think the best to actually demonstrate how important of an improvement it is.
First, the atmosphere is set to be absolutely black. Then I add a quadratic spot to have a physically correct light decay.
The first image show a render without any kind of gamma applied to it
Note: of course, I didn't change the light intensity between the various picture, the beautiful light transition in the third image is only due to the way grays are "shifted" by the gamma settings.
People who renders interior in vue will LOVE what they will discover :)
I read your thread over at Registered users forum, and something is bothering me. You say to allow gamma correction input for texture maps, since they generally have a 2.2 gamma out of the camera , and of course, they do show a lot less dark this way, but if you output a 2.2 gamma to the render, won't the texture be overburnt in the render? I would think an input gamma of 1, and an output of 2.2 would be correct.
This is what is explained in last month issue of 3D World anyway.
In fact, the input gamma of 2.2 will "un-gamma" your image before they are sent to the render engine, that way it "sees" the color in it's own color space (render engine color space = gamma 1, origin of the name "linear").
NB: of course if you were to hand paint or generate procedural texture and have them looking good on a display set to a gamma of let's say 1.8, then you would need to set the input for that particular image to 1.8 too.
As for the output gamma, it really only depends on what you want to do with the picture you render.
you want to work on it in a program that can handle 16 or 32 bits images: in that case, the best is to save it as a float image with a gamma of 1. (Actually here, the gamma isn't very important, it will only tell your software how to show the picture but all data are conserved anyway).
you want the picture to look at its best on your computer and don't really plan on posting it anywhere: choose to save for the gamma of your monitor.
you plan on posting the picture on the web: the safest choice here is probably a gamma of 2.2 since it's the most commonly found (at least among people who actually calibrate their monitor :) )
In my opinion, the best choice is 1 (unless you really don't plan on doing any kind of post-work or compositing on your image. This option allow you to have the full range of data produced by the render engine at your disposal and, for example change the exposition of your image drastically without problems.
I don't know who wrote the article for 3D world, but I can assure you he/she was wrong concerning the input gamma. You want to "feed" your render engine with what it expect to find :)
Oh, by reading this again, I think I know what get you confused: the input field doesn't tell vue to apply a gamma of 2.2 to the picture, but it tells the render engine: "my friend, the picture I feed you with HAS a gamma of 2.2". When the render engine receive this information, it apply a gamma of 0.4545... to "linearize" your image (sorry, this word doesn't exist but what I mean is to move the picture from the srgb color space to the linear space needed by the render engine).
So, I know why it can be confusing now :)
Input = inform the render engine about the existing gamma of the texture map so it can move it to its linear workspace
Output = tell it to produce an image with the gamma you choose burnt into the render.
This is quite interesting because I've been reading a lot about linear workflow recently.
I know in Max, you can "anti gamma" materials to remove the burned in 2.2 from the camera or whatever, then render and save as a 32bit float EXR file and apply whatever curve you want in post.
Would be nice if Photoshop had better support for 32bit EXR files. Nuke is quite expensive! (Although I've now got a freebie copy of Toxik that comes with Max 2011)
My Freebies
Buy stuff on RedBubble
Bruno, I attached a very simple image.
Gamma settings are following:
The cube on the left uses those settings
The cube on the right uses the exact same texture map (a radiant from black to white created in the Gimp and saved with a gamma of 2.2 (srgb in the Gimpt)). The only difference: on the second cube, I load the image with the override checked and load it with a gamma of one)
You can clearly see that the first cube is the correct one (in fact, you could push the test by creating a procedural gradient in vue and render it side by side with the two cubes - since procedural textures are mathematically calculated, they are always linear (unless you add a gamma node of course)
I added some clarifications in the registered forum so I decided to copy them here to, just in case :)
If you dissect the "gamma option" window, you can see it contains three very different type of control.
The top portion of the dialogue box is what I would call a "convenience or helper" section. The most important thing to understand about it is the fact that it has ABSOLUTELY NO INFLUENCE on the rendered image (if you want to verify that, you can create an image, render it with the slider pushed to the minimum, then again with the slider pushed to the maximum, the final image will look exactly the same :)
Does that mean, this portion of the gamma settings dialogue is useless and was added to make the dialogue prettier ? :)
Of course not :) That's what I call "conveniences controls". In this particular case, they allow you to see the colours in the same colour space as your monitor (the gamma you choose) while still sending colours in linear space to your render engine.
So, what exactly happens ?:
Let's say, you set your the gamma of your monitor to be 2.2 and you check all the check-boxes
The input gamma field: This is what I would call an "information" control. It INFORMS the render engine about the kind of data you send it
The output gamma field: This is a "command" box, here you give vue a command, you tell it to output the picture in a determined colour space (as far as I know, only matters if you save in a limited range file format, if you export exr, hdri, float tiff, it doesn't really matter, the full range of informtion will still be saved
I hope this will help to make a few things easier to understand and again, I'm not a professional and English is not my native language :) This "tutorial" is really only aimed at beginners who might have no clues about Gamma, I know professionals already know all that stuff better than I do :)
I have honestly no idea if all this blabbing will be of interests to anyone, but I hope many people will discover the power this new settings offers. I have seen images in the gallery made by much more talented people than I am "killed" by a bad gamma and the harsh light transitions it produces, so, I guess my post is a bit egoistic, I want to be able to enjoy the full talent of this artists once they start using the tool :)
Thanks Abraham,
Very useful compilation of info. I agree the addition of full gamma control is truly one of the huge steps in this version. Even though I knew most of the material you presented already, I still learned a few things and you cleared up a couple of issues I was not sure about.
Thanks again, very much appreciated
TD**
**
Abraham, thanks for all that info on the new gamma options, as well as gamma in general. Really useful!
At the beginning of the thread you posted 3 renders showing the light falloff. You the said that the 3rd image was the one with the most natural light transition. This maybe true from the technical standpoint. But to me the most pleasing is the 2nd picture with the natural film response turned on. Simply because there is a smoother the light transition near the light source (in the 3rd image the area near the light source looks like a white patch).
http://www.eonmusic.ch http://www.artmatica.ch
You are very welcome :)
Eonite, I think, what I don't really like in the second picture is the absence of real black, but I guess it could be fixed with a curve correction in a photo editing program (even more so if exported as 16 bits or float).
One thing I'm sure of, is the fact that we will see much more balanced renders now :)
Quote -
One thing I'm sure of, is the fact that we will see much more balanced renders now :)
I have no doubt :-)
http://www.eonmusic.ch http://www.artmatica.ch
I have a question:
How do you apply an override gamma of 1 in an animated render with rendernodes?
If I render in the viewport I can specify Override Gamma when I go to save, but when it comes to rendering a sequence I don't have any gamma override options?
Note: My gamma display is set to 2.2, I'm rendering 32bit hdri, animated cloud sequence over a rendernode network. Without the override the image looking incorrect in Nuke, with the override applied its perfect.
thanks
Rich
Rich, a 32 bit hdri (or float exr for that matter) should never need to be gamma corrected by the render engine. You should only have to tell nuke (I'm more familiar with fusion but I guess the tools are more or less the same) in what color space you rendered your sequence and nuke should be able to bring it in the right color space in your composition while preserving the full range of data.
The following paragraph only apply if your render without override appear washed out:
What might happen in your case is something a bit more annoying: all sky presets were created with the "old" work flow in mind and they all look wrong when rendered with gamma activated (I have a post about this on e-on forum) and even if it's relatively easy to bring the sky to the right color by applying an invert gamma to the color in the sky color slot, it doesn't work that well with the decay color
At the opposite, if you render appear way too dark in nuke, it's definitively something that need to be corrected in the compositing application itself (I suppose, you can in nuke, like in fusion, set the gamma of your input image in the image input node)
Don't hesitate to post again in this thread if it solves or not your problem, gamma isn't a subject interesting a lot of people, but it would be nice to create a good resource about it, considering how important it is for the final image :)
One thing I just thought about, you can easily change the default gamma output before rendering your sequence and bring it back to normal after that
This should work fine on your sequence and get the job done, but I don't consider it to be the right way of doing it :). The right way should be Output Gamma 1 in vue and provide the information to nuke in the image loader node.
Thanks Abraham!
I agree gamma is one of those things that people are so unaware of.
O.K. I have some cool stuff:
Previously I could only render HDR over the animation render farm which have me a (default sRGB) colorspace.
In the Animation Render option I ignore the fact it doesn't give you an option for '.EXR' and I pop the '.exr' extension at the end of the color channel file path.
This will render over the farm a Linear float '.exr' file.
To test it I'm dropping it directly into Nuke, the colorspace is (default linear. In Nukes 'viewerProcess' I flick between sRGB and None. When I view with (default linear) and (sRGB) it looks like it does in Vue. When I view (default linear) and (None) it comes up darker. I think this is what is meant to happen?
Also when I render in Houndini/3Delight the gamma and color looks correct with my LUT.
So that is my process now.
Now I have to find a way to render a mulitpass cloud Mask in the animation render options :(
Nice to see you found a solution Rich :)
Yes, the way your switch reacts are what is to be expected (you handle the image at its full potential while seeing it as you want your final comp to look like. So all is fine, and it's the correct way of handling stuff.
I have no clue yet for the cloud mask but if I "tumble" onto something, I will let you know :)
The gamma unawarness is really a sad thing, a lot of people are talented and have their image ruined by the harsh shades transition. That's probably why the introduction of a good handling of it in vue is such a major improvement in my opinion.
You can not realy prefform linear workflow before Vue 8.5. You can workaround and simulate with lighting control, but in Vue 8.5 it's mutch easer (gamma control) It would be nice if they added not just a global gamma control, per individual material.
I am finishing recording tutorial about Linear workflow, it should be out shortly.
This is a good news Volter, I really hope more and more people get to know what Linear workflow is and also understand it's not only some "feature for professionals only" but a tool that benefit absolutely everyone.
I guess the next two steps in my "vue happiness voyage" would be the apparition of energy conservative materials and a physically scaled sun, sky and atmosphere but I guess, even if I don't desperate to see it happens some day, it will take times, those are not exactly easy changes and improvements to do.
I uploaded three tutorials about Linear workflow in Vue 8.5
Let me know if they was helpfull.
http://www.geekatplay.com/tutorials5.php
#167, 168,169
I have watched the tutorials and I understand more what the Gamma correction does, but I am still a bit unclear about what to do for the washed out appearance of the render... Re-rendering a scene where the lighting was "ok" looks very washed out with gamma on, even at lower than 2.2.
LVS - Where Learning is Fun!
http://www.lvsonline.com/index.html
Quote - I have watched the tutorials and I understand more what the Gamma correction does, but I am still a bit unclear about what to do for the washed out appearance of the render... Re-rendering a scene where the lighting was "ok" looks very washed out with gamma on, even at lower than 2.2.
Just a thought
If natural film response was turned on.
You might try again with natural film response turned off.
Frank Hawkins/Owner/DigitalDaydreams
Frank Lee Hawkins Eastern Sierra Gallery Store
My U.S.A eBay Graphics Software Store~~ My International eBay Graphics Software Store
Peggy, if the light looked okay with a gamma of 1 it will never be correct with a gamma of 2.2 unless you adjust the intensity.
Basically, especially when using quadratic lights, we have to crank up the light way behind what is actually "physically correct" to get enough light with a gamma of 1. So, as soon as you correct to 2.2 everything get lighter.
My suggestions:
I hope it will help you. The introduction of a linear work-flow in vue is a really great thing in my opinion, but the downside is, we now work with "legacy" presets and, with the exception of those using texture maps only, they all need to be updated to match the more physically accurate gamma of 2.2 now used.
Also, ddaydreams, is right, beware of the natural film response checkbox. It really tends to wash out renders (in fact, you even see that during the calculation phase for a radiosity render where the black part turn to gray
Thanks Abraham! That does help clear this up for me.
LVS - Where Learning is Fun!
http://www.lvsonline.com/index.html
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
I started talking about this subject with Eonite in his "Vue Clouds" post but I think it might be a good idea to start a new thread for it (for the sake of keeping the Vue Clouds thread on topic if nothing else.
So here, I simply paste the text I posted on the other thread.
It is indeed complex when it comes to finding the right settings (in fact, I became aware of the whole "linear workflow" problem about 5 years ago when it became "the subject" among mental ray users aka "to be linear or not to be".
I haven't had time to play a lot with 8.5 yet (my new computer components actually arrived on Tuesday, so as you can imagine, still installing, customizing and stuff).
Now, when it comes to "using gamma or not", they are (as for all things in life I guess) many schools.
Here are for me the important points:
Always using the right gamma for the various color inputs (most of the time it will be 2.2 since most images are created with this gamma - main exception being the various REAL high dynamic range images which should not be corrected - gamma = 1). A good way to know if 2.2 is the right setting is simply to open the image in your image editor: if it looks right on your screen, then its gamma is the same as your screen, probably 2.2)
E-on engineers did something very clever in their implementation: any texture used in one of the gray scale channel automatically use a gamma of 1, which is what you always want (a gamma of 2.2 for a bump or displacement channel is BAD :) )
The right settings for the "Gamma option" dialog are in my opinion:
Display Gamma = the gamma to which your monitor is calibrated (usually default to 2.2 but if you use a hardware calibrator, you can find out that your display looks "better" with a gamma of 1.8, sometimes even less on very high end monitors).
Affect Color Editor = checked (that way, the color editor apply a negative gamma to the color switcher, what it does is showing you the color you want, but sending to the render engine the color it excepts).
Affect Material Preview = checked (for the same reasons as above).
Affect Color Functions Preview = cheked (same reason)
Afect Scalar Functions Previews = checked (same reason)
Preview Gamma and exposure in main view = checked (it allows you to see the final result as saved for your current display gamma settings, if unchecked things will look darker and you might tend to increase the lighting intensity and send "bad" information to the render engine.
Texture Maps Input Gamma = 2.2 (you can override on a per texture basis when loading them if you know that a texture was created in a different color space / gamma space.
Output Gamma = 1 or your display gamma (here they are no right or wrong, it all depends on what you do with the image: basically, if you save it to a low dynamic range format (8bpp) then it's better to back the gamma in it (use the gamma of your display or, 2.2), if you save to a high dynamic range format (16 bpp or more) then, go for an output gamma of 1, it will give you much more freedom in post composition.
As for the clouds being washed out, I noticed that too, there might be two reasons to that: maybe e-on didn't yet (or forgot) to take the gamma correction into account for the auto-exposure control (an easy fix is to lower the exposition, around half a stop seemed to be good here)
I hope it's helpful, I'm aware that my poor English is a bit limited to explain such a subject :) (French are NOT gifted for foreign languages :) )