When to apply gamma correction?

[futar]

I"m posting a simple blend file in which I’m trying to get N30N’s two codes to work.

@N30N

I just did a quick test and you can enable the pynode only at render time with the following.

Use the following script link on the render event…

from Blender import Registry 
 
if Registry.GetKey("gammaNode"): 
    Registry.RemoveKey("gammaNode") 
else: 
    Registry.SetKey("gammaNode", {"rendering": True})

Then use this pynode…

from Blender import Node, Registry 
 
class GammaCorrection(Node.Scripted): 
    def __init__(self, sockets): 
        col = Node.Socket("Color", val = 4*[1.0]) 
        gamma = Node.Socket("Gamma", val = 2.2, min = 0.0, max = 10) 
        clampA = Node.Socket("RefLow", val = 0.03, min = 0.0, max = 1) 
        clampB = Node.Socket("RefHigh", val = 0.9, min = 0.0, max = 1) 
        sockets.input = [col, gamma, clampA, clampB] 
        sockets.output = [col] 
 
    def __call__(self): 
        processor = lambda x: x ** self.input.Gamma * (self.input.RefHigh - self.input.RefLow) - self.input.RefLow 
         
        if Registry.GetKey("gammaNode"): 
            self.output.Color = map(processor, self.input.Color) 
        else: 
            self.output.Color = self.input.Color 
 
__node__ = GammaCorrection

only I’m not getting the results I expected. I thought the use of these two codes would prevent the material preview from showing the result of the ‘gammaNode’ but allow the result to be seen in the final render. At the moment I get the complete opposite. The material preview does show the gamma correction and the final render doesn’t show any gamma correction.

Could someone please show me where I might be going wrong or tell me if I have simply misunderstood the use of this pynode and scriptlink combination. It would be greatly appreciated.

Many thanks

Attachments

gammacorrection.blend (167 KB)

[N30N]

@futar

I"m posting a simple blend file in which I’m trying to get N30N’s two codes to work.

I modified it into one pynode to make usage a bit easier (warning: old script link will conflict if not removed).

@futar

only I’m not getting the results I expected. I thought the use of these two codes would prevent the material preview from showing the result of the ‘gammaNode’ but allow the result to be seen in the final render. At the moment I get the complete opposite. The material preview does show the gamma correction and the final render doesn’t show any gamma correction.

I tested your blend file and it’s working as you described it should. Perhaps you had the old node loaded before and didn’t click the update button?

[futar]

I opened the file this morning and surprisingly it did indeed work how I had previously expected it to. Perhaps it was just a case of me needing to click the update button. Sorry for causing any confusion and thanks for clearing things up.

Also thanks for simplifying the code down into just one pynode. That’s great!

[Maurice_Raybaud]

Thank you guys, this thread is really helpfull.
I’m having a hard time trying to set the world colors correctly. They don’t seem to be accessible through nodes so I try to tweak from looking at the render, but I never seem to get a saturated light blue after composite gamma correction… Any idea?

[N30N]

@futar

Perhaps it was just a case of me needing to click the update button.

Actually, now that I think about it, the second render event on one of your renders must not have fired for some reason coursing the problem. I’ve not gotten this while testing and unforchenly there’s not much I could do about it via Python. At least relaunching blender doesn’t take long.

@Maurice Raybaud

I’m having a hard time trying to set the world colors correctly. They don’t seem to be accessible through nodes so I try to tweak from looking at the render, but I never seem to get a saturated light blue after composite gamma correction… Any idea?

Set RenderOnly:0 and connect to a output node, then use the colour sampler to pick the colour. :eyebrowlift:

[Maurice_Raybaud]

Before trying your node, I had already tried sampling from an image that had rendered better (using a hdri sky map but I don’t want the map) with no success (EDIT: Now I guess this was predictable since that image was not 2.2 corrected material or texture but a 0.45 corrected render output, right?). The same happened at first with your method though picking a 2.2 corrected color ! But it seems in the end, that the problem was actually caused by the rest of my node setup. Thanks for the PyNode and the tip, they should allow me to continue learning linear workflow just in time as I was about to give up for lack of time.

[futar]

I have a further question to do with Ambient Occlusion.

If you read this page (it’s about Lightwave which I’ve never used, but it’s still useful information)…

http://www.happy-digital.com/freebies/tip_gamma.html

It mentions towards the bottom of the page that even after doing all the gamma correction the image still appears too bright due to the ambient light intensity. I too am still experiencing renders which are too bright even after applying 2.2 gamma correction to the materials, using N30N’s fantastic pynode, and then reverse gamma correcting the final render with a 0.45 gamma node in the compositor.

My question is… does the ambient occlusion pass need gamma correcting too or would it suffice just to lower it’s intensity?

I’ve tried using an RGB Curve in the compositor just before the 0.45 gamma node to bring back some of the darkness in the shadows but this also has the undesired effect of changing dark colours to a practically black colour.

Thanks for any replies. I too am finding this thread immensely useful.

[Maurice_Raybaud]

YPoissant’s experiments seem to show that the HSV node to change the value is less destructive to the dynamic range than RGB curve does this solve your problem?
I guess that if ambiant occlusion uses sky color, the sky color needs to be picked like mentioned in the two previous posts. Anyway, I would say it just needs to go through a 0.45 gamma node at the end like all the rest but I am pretty new to all this…

[harkyman]

I’ve been curious in all of these threads about gamma correction and linear workflow to really see the proof. I really do understand the workflow, as well as color spaces and correction in general (I do digital color correction for a high end commercial printing company), but, much like in my own business, I have yet to see the impact. Where I work, we can argue about gammas, color spaces and icc profiles all day long, but in the end, a well-calibrated monitor that matches the physical press sheet, a good eye, and strong knowledge of your tools is what you need to get a great result.

So, I guess what I’m asking is: what will all of these mathematical gymnastics earn me? Why bother? If my renders come out as I expect them to, and lights and shadows look good, and I achieve a nice dynamic range in my images with no blow-outs on the high or low end, why should I bother? Am I just gamma correcting everything in my head well enough that it’s not an issue for me?

I’m suspecting that this is only really an issue in a multi-user, multi-platform, multi-application pipeline. In that case, you really do need to have absolute predictability from end to end. Other than that, though, how is this not a colossal waste of time?

[ypoissant]

@futar

It mentions towards the bottom of the page that even after doing all the gamma correction the image still appears too bright due to the ambient light intensity. I too am still experiencing renders which are too bright even after applying 2.2 gamma correction to the materials, using N30N’s fantastic pynode, and then reverse gamma correcting the final render with a 0.45 gamma node in the compositor.

Ambient light intensity is not the same thing as ambient occlusion. Ambient light is a lighting trick while ambient occlusion is a shadowing trick. So, though the underlying conclusion is correct, the assumptions when comparing AO and ambient light are very different.

My question is… does the ambient occlusion pass need gamma correcting too or would it suffice just to lower it’s intensity?

AO needs gamma correction too. This is no exception. However, if your AO seems too bright, it might be due to the AO distance setting which may be set too short.

[ypoissant]

@harkyman

So, I guess what I’m asking is: what will all of these mathematical gymnastics earn me? Why bother? If my renders come out as I expect them to, and lights and shadows look good, and I achieve a nice dynamic range in my images with no blow-outs on the high or low end, why should I bother? Am I just gamma correcting everything in my head well enough that it’s not an issue for me?

If you are happy with your current renders, then, indeed, you should not bother with this gamma stuff.

This is not for multi-member teams, although, this would help consistency. This is really for getting realistic lighting. It is true that one can get “good looking” renders without gamma correcting. But to get “correct” lighting results without gamma correction requires a lot of work for compensating the color space distortion. It requires that additional lights be placed in the scene to fill dark spots and corners. It requires that the render be rendered in passes so the corrections and color balance can be adjusted through compositing.

And when rendering with a GI or unbiased renderer, all the usual CG tricks for compensating gamma does not work anymore. It is no coincidence that this Linear Workflow have started to be a real concern in the communities which started using GI renderers. They had to figure this gamma correction stuff because all the usual tricks did not work.

[PapaSmurf]

Ambient light intensity is controlled by the material Amb sllider that specifies the % of ambilent light affects the material, and the Ambient light color itself, set in the world settings. http://wiki.blender.org/index.php/Manual/Ambient_Light

[Maurice_Raybaud]

If that can help you, harkyman, I thought your renders for The Beast were so realistic that I mistook them for an external renderer works

If it is something else than both gamma and color corrections applied, may I ask anyone what tone mapping really is? Is it worth opening another thread?

[N30N]

@Maurice Raybaud

may I ask anyone what tone mapping really is?

http://en.wikipedia.org/wiki/Tone_mapping

[PapaSmurf]

Maurice, yes, a new thread on the that node. I cannot find any developer doc on it, and I dont think it has anything to do with gamma

[futar]

I’ve been attempting to use N30N’s gammanode now for a few days and I’m not sure that it functions properly. To me it seems to effect how the light reflects off dark materials in an inaccurate way. Also when separating out the shadow pass in the compositor, dark materials appear red in a viewer node. If I disconnect the pynode the red is gone. Surely red is not supposed to appear in the shadow pass?

This could just be down to my inexperience on using nodes, but something doesn’t seem quite right.

Attachments

[Alvaro]

@harkyman

I’ve been curious in all of these threads about gamma correction and linear workflow to really see the proof. I really do understand the workflow, as well as color spaces and correction in general (I do digital color correction for a high end commercial printing company), but, much like in my own business, I have yet to see the impact. Where I work, we can argue about gammas, color spaces and icc profiles all day long, but in the end, a well-calibrated monitor that matches the physical press sheet, a good eye, and strong knowledge of your tools is what you need to get a great result.

So, I guess what I’m asking is: what will all of these mathematical gymnastics earn me? Why bother? If my renders come out as I expect them to, and lights and shadows look good, and I achieve a nice dynamic range in my images with no blow-outs on the high or low end, why should I bother? Am I just gamma correcting everything in my head well enough that it’s not an issue for me?

I’m suspecting that this is only really an issue in a multi-user, multi-platform, multi-application pipeline. In that case, you really do need to have absolute predictability from end to end. Other than that, though, how is this not a colossal waste of time?

Images and in general GPU output was corrected to be shown in old CRT monitors, since CRT phospor tecnology did not have a linear response to the electrical input, it had a curve response. As a solution to that problem, images were just gamma corrected using the inverse curve to monitors’ one. Then they were input in the CRT displays, getting as a result a linear gamma.

By using the linear workflow in the render engine, you are in fact discarding the harware component in your workflow. The render engine gets the textures (and colors) input in their original linear space, and the render output is also plain linear.

Gamma correction in a finished render is in fact a post processing task, and the value used for that gamma has to do with the device (and the color space if you wish) you are watching the render on. You can do the finished render gamma correction in the 3D program (if implemented), or you can do it in an image editor using a HDR format, getting the very same result.

Gamma Correction in renders should be a non-destructive editing process, a temporal factor depending on the device used to display that image. The whole CGI industry is slowly progressing towards linear, non - destructive, high bit-depth format storage for content creation.

The problem with linear workflow is that it must be explained easy, and it should be explained as a hardware-software issue, rather as a lighting issue as I see in these threads.

[MikeJ]

@N30N

I just did a quick test and it’s possible to enable the pynode only at render time.

from Blender import Node, Registry, Text, Scene

class GammaCorrection(Node.Scripted):
    def __init__(self, sockets):
        col = Node.Socket("Color", val = 4*[1.0])
        gamma = Node.Socket("Gamma", val = 2.2, min = 0, max = 10)
        refLow = Node.Socket("RefLow", val = 0.03, min = 0, max = 1)
        refHigh = Node.Socket("RefHigh", val = 0.9, min = 0, max = 1)
        render = Node.Socket("RenderOnly", val = 1, min = 0, max = 1)
        sockets.input = [col, gamma, refLow, refHigh, render]
        sockets.output = [col]

        sce = Scene.getCurrent()
        txt = """
from Blender import Registry

if Registry.GetKey("gammaNode"):
    Registry.RemoveKey("gammaNode")
else:
    Registry.SetKey("gammaNode", {"rendering": True})
"""
        try:
            Text.Get("renderGamma")
        except:
            Text.New("renderGamma").write(txt)
        
        if not "renderGamma" in sce.getScriptLinks("Render"):
            sce.addScriptLink("renderGamma", "Render")

    def __call__(self):
        processor = lambda x: x ** self.input.Gamma * (self.input.RefHigh - self.input.RefLow) - self.input.RefLow

        if not self.input.RenderOnly or Registry.GetKey("gammaNode"):
            self.output.Color = map(processor, self.input.Color)
        else:
            self.output.Color = self.input.Color

__node__ = GammaCorrection

Sorry for the necro, but I am trying to use this script in 2.49b and receive a “not a valid dynamic node Python script” error message. I am unable to find any reference to this error message on either this forum or on the Wiki.

Is anyone else using this script successfully?

Mike