Video: The Beginners Explanation of Gamma Correction & Linear Workflow

[Matt]

I've done a video tutorial on the very _basics_ of what gamma correction and linear workflow is, and why you need to use it, especially if you're lighting interiors.

I realise there are many threads and tutorials on the subject, but none of them explained to me what gamma is, and why it exists anyway!

This is my take on the explanation.

PLEASE bear in mind this is meant to be _very_ simplistic, and almost certainly leaves out certain topics or concepts. It is designed to help those, like me, who have heard about it, wanted to use it, but were put off by the technical aspects of it.

I just hope enough of my understanding on this is correct to be useful!

Cheers
Matt

Video Tutorial: The Beginners Explanation of Gamma Correction & Linear Workflow (http://www.pixsim.co.uk/video_tutorials/The_Beginners_Explanation_of_Gamma_Correction_and_ Linear_Workflow.zip)
Quicktime H.264 15.4MB Zipped

http://www.pixsim.co.uk/gfx/Explaining_Gamma_Title.png

[Matt]

Oh, and here's the PDF used in the video if you want it ...

The Beginners Explanation of Gamma Correction and Linear Workflow.pdf (http://www.pixsim.co.uk/downloads/The_Beginners_Explanation_of_Gamma_Correction_and_ Linear_Workflow.pdf)

[evenflcw]

I'm definitely a beginner of this subject. So it helped loads (100% accurate or not)! Very nicely put together. Thanks alot!

[adhesiveX]

Thank you Matt! I really enjoy your tutorials,they are always so clear ,concise and to the point.

[AdamAvenali]

It is designed to help those, like me, who have heard about it, wanted to use it, but were put off by the technical aspects of it.

yes, yes and yes! :thumbsup: i can't wait to check this out tomorrow!

[probiner]

Thanks a lot Matt i don't understanding nothing about this and i might just start to get it now.

Cheers

[virtualcomposer]

For some reason I couldn't get my wife to watch this video for her birthday present. Lol. She said something like she'd rather see a romantic comedy. I mean what could be more romantic then gamma correction and linear workflows? Lol. Great tutorial by the way!

[nikfaulkner]

hell yeah, thanks matt. i'll check it out later.

thanks mate

n.

[-EsHrA-]

cheers Matt!

mlon

[JeffrySG]

Great video, Matt! Thanks!

Just a quick question. How do you go about picking colors in LW/modo for objects in let's say a procedural texture on screen? Isn't it hard to pick a color that you want as it would probably be much darker than what you needed? or is that what you use the jovian picker to help you with?

Also, is there a way in LW to apply a 2.2 gamma to every render after it's done so you don't need to open each render in PS to apply the gamma correction to check the image?

[Matt]

Just a quick question. How do you go about picking colors in LW/modo for objects in let's say a procedural texture on screen? Isn't it hard to pick a color that you want as it would probably be much darker than what you needed? or is that what you use the jovian picker to help you with?

For LightWave:

You need to use Jovian (by Ken Nign) (http://www.joviancolorpicker.com/)or SG_CCTools (By Sebastian Goetsch) (http://www2.informatik.hu-berlin.de/~goetsch/CCTools/)

For modo:

It colour corrects the pickers automatically, even the Windows one apparently (I didn't know that at the time of the video - doh!)

Also, is there a way in LW to apply a 2.2 gamma to every render after it's done so you don't need to open each render in PS to apply the gamma correction to check the image?

Yes, in the Image Processing Tab on the Effects panel, pull down on FP_Gamma, put your target gamma in there.

[kosmodave]

:thumbsup:

Many thanks for this video Matt, It's funny how I missed this issue and have struggled to get some renders to look right without using loads of lights, now I know.

Like all your videos, clear and to the point and should all be bundled with any Lightwave purchase. :)

Dave,

[art]

I'll just add my Thank You! :thumbsup:

[JeffrySG]

Thanks for that additional info, Matt!

Sometimes hearing a simple explanation of a topic is all you need for everything to really click. Good job!

[thekho]

Great tutorial! Thanks, Matt :thumbsup:

[adk]

Cheers a bunch Matt ... nice, simple, and informative :thumbsup:

[JeffrySG]

http://www.ypoart.com/tutorials/tone/index.php

I found this site that has a bunch of detailed info that goes along with Matt's great video.

[Matt]

http://www.ypoart.com/tutorials/tone/index.php

I found this site that has a bunch of detailed info that goes along with Matt's great video.

Wow, that's a cool site! Thanks!

[Red_Oddity]

Also, if you really want to delve into this, get Christian 'Blochi' Bloch's HDRI Handbook, available nn all Amazon stores.

http://www.hdrlabs.com/book/index.html

It's a good read, focused on folks like us, written by someone like us.

[JeffrySG]

Well Matt got me thinking so I made a small node tree that will let you pick any color you want and it will adjust the color so it works in the linear color space. This is assuming that you're working on a monitor with a gamma of 2.2.

If you are working with a different monitor gamma you will need to: (1/monitor gamma) to get the value that you put into the gamma input on the gamma node in the tree. Right now it is set for 0.45 (1/2.2) which will adjust for a gamma of 2.2 but you can set it to anything you need.

You can copy and paste this node tree into any node setup you might need to use color such as a solid color or into any other color input of a procedural or a material node.

You will need Mike's free db&w Tools V1.4. (http://www.db-w.com/component/option,com_remository/Itemid,84/func,fileinfo/id,63/)

Thanks to Mike and James for their help on some questions I had!

I included a .nodes and a .srf in addition to this pic in the zip file. Sometimes I was crashing while trying to re-load the .srf file so make sure you save and try loading the .nodes if you have problems.

Enjoy!

77874

http://i34.tinypic.com/qxpfm9.png

[RenderBlur]

Jeff,

Thanks, this looks like it will be very useful and I really like how you used Scalars just to comment the Node tree, I don't think I've seen that before but it's great!

Q: in the make Gamma adjustment step, I notice the Y Vector doesn't have the gamma applied in the Wrap(3), which then outputs to blue. Is there a reason for that?

thanks,
-Jim

[Lightwolf]

You will need Mike's free db&w Tools V1.4. (http://www.db-w.com/component/option,com_remository/Itemid,84/func,fileinfo/id,63/)

Since you use those anyhow... why not use the simple colour correction node which is a part of the plugin pack, and has a gamma control as well?

Cheers,
Mike

[JeffrySG]

Jeff,

Thanks, this looks like it will be very useful and I really like how you used Scalars just to comment the Node tree, I don't think I've seen that before but it's great!

Q: in the make Gamma adjustment step, I notice the Y Vector doesn't have the gamma applied in the Wrap(3), which then outputs to blue. Is there a reason for that?

thanks,
-Jim

Jim, if it's not connected it was a mistake. That gamma node should be in all 3 of the Wrap nodes. Thanks for noticing that!

[JeffrySG]

Since you use those anyhow... why not use the simple colour correction node which is a part of the plugin pack, and has a gamma control as well?

Cheers,
Mike

Come on Mike, you always have to make things so easy... lol :thumbsup:

Wow... I didn't even notice that the 'simple color corrector' had a gamma adjustment! :bangwall:

I'll update those files and re-post!
Cheers!

edit:
Here's the new simple way to do it. You still need Mike's free plugins just fyi, but there is not really any setup anymore because Mike makes great plugins for us!

This is a .nodes file
In this one you simply put in your color and working gamma. It does any conversions for you.
So in this case I input 2.2 and it gets converted automatically to the inverse gamma of 2.2 which is 0.45
77878
http://i38.tinypic.com/ncibn4.png

[JeffrySG]

...and I really like how you used Scalars just to comment the Node tree, I don't think I've seen that before but it's great!
thanks,
-Jim

To be honest I saw someone here do it so I learned it from them. And I think it might have been Matt, if I remember correctly. :)

[Deadlyforce]

Isn't it easier with SG_CC_Picker ?

[Matt]

Isn't it easier with SG_CC_Picker ?

Yes, and Jovian.

But still, it's good to know just in case!

[JeffrySG]

Isn't it easier with SG_CC_Picker ?

I didn't think there was a MacUB version of that plugin? (I'm running MacUB)

And Jovian is a commercial plugin. (I'm sure it's great though) :)


ps. I didn't mean to hijack this thread either, Matt... sorry... :)

[Matt]

I didn't think there was a MacUB version of that plugin? (I'm running MacUB)

And Jovian is a commercial plugin. (I'm sure it's great though) :)


ps. I didn't mean to hijack this thread either, Matt... sorry... :)

There is a free version of Jovian, but I think the gamma part is in the full version. It costs bugger all though for the amount of extra functionality it gives you.

(And no, I don't benefit from sales, in case anyone wondered!)

[biliousfrog]

I've just read through the PDF and already the penny has dropped.

I thought that I kinda understood what it was all about but the results where never anything that I thought was 'wow'...but the bit about changing the gamma of the textures into linear so that they aren't washed out...that's when the lightbulb fizzled into life.

I shall now settle in with a nice cuppa to watch the video :)

[Riff_Masteroff]

Very, very good video Matt. For me, it hits home with the dark render being proper for HDR file output.

The work flow I am trying to self-nail-down is LW to Fusion to Final Output. What I am getting, so far, is that I need to preview the render in LW with gamma correction - but not output the render with gamma correction. Then after import to Fusion, A) I should apply gamma correction, B) compress the range (tone mapping) and adjust, and C) finally output to either a printable image format or to an animation format. This, as of yet, not up and running work flow assumes LW rendering to Lightwolf's magical exrtrader and then reassembling the results for special adjustments along with G-correction/T-mapping within Fusion.

[Lightwolf]

This, as of yet, not up and running work flow assumes LW rendering to Lightwolf's magical exrtrader and then reassembling the results for special adjustments along with G-correction/T-mapping within Fusion.
Actually, exrTrader helps you a little with that, as there is a Display Gamma option for the VIPER preview.
And if you enable "Post-apply Display Gamma" then the display gamma will be baked into the image... after having been saved by exrTrader, but prior to LW saving it or displaying it after a render.

That should handle the output for you.

Cheers,
Mike

[Lewis]

Nice stuff Matt, very nice :) :).

[biliousfrog]

Just bought Jovian and the colour libraries that you produced Matt are worth the price alone...no more sampling RAL colours in Photoshop and transferring the RGB values.

I'm also reading through the Yves Poissant weblink that was posted, lots of great info on there and it's much easier to understand after Matt's guide.

Here's the link again: http://www.ypoart.com/tutorials/tone/index.php

[MooseDog]

Also, if you really want to delve into this, get Christian 'Blochi' Bloch's HDRI Handbook, available nn all Amazon stores.

http://www.hdrlabs.com/book/index.html

It's a good read, focused on folks like us, written by someone like us.

kinda meaningless post on my part, but just felt compelled to vote for this as well. after reading this there's next to nothing you won't understand on this subject.

christian also has a site up and running with some great resources:

HDRLabs (http://www.hdrlabs.com/news/index.php)

[Cageman]

A great video and PDF that deals with this subject in a "layman terms" kind of way. As always, your videotutorials are some of the best out there!

:thumbsup:

[adhesiveX]

For LightWave:




Yes, in the Image Processing Tab on the Effects panel, pull down on FP_Gamma, put your target gamma in there.

Discovered a realtime preview of gamma correction by using the wavefilter
plugin in the image processing tab. In the wavefilter plugin interface under the color tab dail in the gamma value and make sure you do a F9 render then set the preview option within the wavefilter plugin to last render and presto,... realtimetime preview of your image while you adjust settings.

[Matt]

Discovered a realtime preview of gamma correction by using the wavefilter
plugin in the image processing tab. In the wavefilter plugin interface under the color tab dail in the gamma value and make sure you do a F9 render then set the preview option within the wavefilter plugin to last render and presto,... realtimetime preview of your image while you adjust settings.

Wow, what a cool filter, never knew it existed before!

[Riff_Masteroff]

Quote Page 3:
"Modern flat panel displays do not have the same physics as CRT monitors so they don't have the built-in darkening gamma (2.2). However, to avoid having to make multiple versions of images in order to look right on all possible displays, it was universally agreed that flat panel displays wil have an artificial gamma LUT built into them so that they replicate the apperarance of CRT monitors"

http://www.swdfx.com/PDF/Nuke_Color_Management_Wright.pdf

[Matt]

Quote Page 3:
"Modern flat panel displays do not have the same physics as CRT monitors so they don't have the built-in darkening gamma (2.2). However, to avoid having to make multiple versions of images in order to look right on all possible displays, it was universally agreed that flat panel displays wil have an artificial gamma LUT built into them so that they replicate the apperarance of CRT monitors"

http://www.swdfx.com/PDF/Nuke_Color_Management_Wright.pdf

Yes this is correct, I deliberately didn't mention it to avoid complicating the basics. But the resulting effect is the same, both display types have gamma applied.

[Riff_Masteroff]

. . . I deliberately didn't mention it to avoid complicating the basics. . .

Yes, of course, agreed! When applying the full gamut (lol) of gamma correction, tone mapping and other tweeks, the goal is "how another average person perceives our output".

But , I believe, we all need to note in our subconscious that humanity is quite diverse. The mathematical construct of human perception isn't right WITHOUT the qualification: AVERAGE HUMAN.

http://en.wikipedia.org/wiki/Color
. . . "While most humans are trichromatic (having three types of color receptors), many animals, known as tetrachromats, have four types"
. . . "As many as half of all women are retinal tetrachromats."
. . . "For some of these retinal tetrachromats, color discriminations are enhanced, making them functional tetrachromats."

RGB might work ok for you and me, but maybe not for your wife. That is a big deal!

[Hieron]

Thanks Matt, great video!
Really usefull

[yaschan]

For some reason I couldn't get my wife to watch this video for her birthday present. Lol. She said something like she'd rather see a romantic comedy. I mean what could be more romantic then gamma correction and linear workflows? Lol. Great tutorial by the way!

It's my wife's birthday today.. I must ask her if she wants to watch it with me.. like you know tonight it's gamma correction time! Maybe she will sleep..
Seriously speaking, gamma correction is such important topic when we produce commercial graphics. I look forward to watch this! Cheers

[Matt]

For some reason I couldn't get my wife to watch this video for her birthday present. Lol. She said something like she'd rather see a romantic comedy. I mean what could be more romantic then gamma correction and linear workflows?

Tell her you want to "gamma correct" her "linear workflow" in the most romantic way possible, that should do the trick!

:D

[JeffrySG]

tell her you want to "gamma correct" her "linear workflow" in the most romantic way possible, that should do the trick!

:d

lmao

[phillydee]

Late in getting this reply posted, but:

Thanks, Matt!!!

Cheers! Post when you've hit 10,000 posts, I'll crack open a cold ale in your honor.

[Marshun]

Simple and right to the point. Now I'm better understanding Gamma.

Excellent, Matt.

Thanks

[Animotor]

Thank you very much for this tutorial!

[nickdigital]

Excellent video tutorial. I wish all video tutorials were as well organized and laid out like this one.

Thanks for putting this one together.

[toby]

Just had a :foreheads moment while (finally) trying a linear workflow in lw -

HDRs that have been gamma'ed up to look normal on our monitors have also had the light sources drastically reduced! The gamma curve is pinned at 0 and 1 (those values never change), so raising the range between 0 and 1 (which is what 2.2 gamma does) will lower the value of anything above 1, just like a spline or a bezier curve. The higher the value above 1 the more it's affected, and can easily cut your light source in half. The result is much different lighting, darker of course but also much more ambient and less directional.

Makes linear working even more important

[Matt]

Just had a :foreheads moment while (finally) trying a linear workflow in lw -

HDRs that have been gamma'ed up to look normal on our monitors have also had the light sources drastically reduced!

Do you mean you're gamma correcting HDR light probes??? If so, DON'T do that!!!!! They need to be left linear!

In order to display a linear image on screen, it needs to be encoded down to 8-bit. To understand what needs to happen, think of it in this way. Imagine you have a very large box full of items, this represent our linear image. You also have a much smaller box, this represents an 8-bit image. You want to place all of those items from the large box into the smaller box. Obviously, not all of the items are not going to fit in, you’re going to have to leave some items out. But which items do you decide to leave out?

Well, this is what ‘Gamma Encoding’, or ‘Gamma Correction’ does. It decides which parts to leave out based on what we know about how the eye sees luminance. Simply speaking, Gamma Correction ‘chooses’ the range of luminance values in the linear image data our eyes can percieve changes in, and throws away the rest. The purpose of this whole process is to store linear luminance data in 8-bit format. The fact our eyes only see certain ranges helps make this process possible.

But this is only true for the final image, your textures, probes, colours etc need to be left linear (if they were) or de-gamma'd if they had gamma in already.

[Soth]

im using linear rendering only now... hc 2007 is stable enough that ive installed it on even our renderfarm... 2006 was crashy... ;)

...but, seriously is so much easier to do good looking renders using linear colour workflow.

[Matt]

im using linear rendering only now... hc 2007 is stable enough that ive installed it on even our renderfarm... 2006 was crashy... ;)

...but, seriously is so much easier to do good looking renders using linear colour workflow.

It's cool isn't it! Just makes it easier to get nicer results (for not much extra effort).

Now, if only FPrime would have a simple Gamma setting in the preferences. :(

[Matt]

BTW: I'm gonna do an update to the video, as I made some incorrect assumptions as to what Gamma is and why Gamma Correction exists.

But in a nutshell (and very much in laymen terms):

What is Gamma?

Gamma (when talking about displays) is the name given to the 'curve' that describes the relationship between the 'input signal' and the 'output luminance'.

NOT as I mention in the video the 'correction' curve.

What is the purpose of Gamma Correction?

The purpose of Gamma Correction is to turn a linear signal (in terms of video) or data (in terms of images) into 8-bit colour space. Gamma Correction does this by taking advantage of the fact that we can only see certain ranges of luminance. So it's purpose is to encode the linear data efficiently for 8-bit.

Is it NOT to correct the fact that old CRT monitors have a natural Gamma curve.

[Soth]

It's cool isn't it! Just makes it easier to get nicer results (for not much extra effort).

Actually is easier. I am getting 'There' with lighting much quicker.

Regarding FPrime, I hope we will be able to render in the CORE after 1.0, native previewer should be so much less hassle free than any external solution.

LW HC OpenGL renders it (hihi) unusable when animating, but you can light and leave rendering over weekend on 12 computers and there will be no single crash. Previous one (2006) was crashing every few frames.

[Tobian]

Yeah I had to wonder about that and the power curve of the monitor. It's more because our eyes naturally have a non-linear response curve, so that we can both see in very low light environments (not as good as some animals, but better than nothing) and not have our eyes blown out of our head from brightness :D That and if LDR images weren't stored with a built-in colour curve, you'd get horrendous stepping issues, precisely because they aren't stored in HDR formats. Case in point, I recently used the image editor to gamma adjust an image stored in LDR format, to give it a 0.4545 gamma adjust, so that when the post-gamma was applied, it didn't blow out. Unfortunately (apparently) the image editor works in the image-format bit depth (8bpp) and saves out an image in that space, for it's use, so it rendered with stepping in the darks. Using the node editor instead did it correctly as all transforms in the node editor are performed in 32bpp.

and Matt: I think Toby was talking about some *bad* HDR's which exist in 2.2 gamma colour space. Just because HDR's are naturally in 1.0 doesn't stop people adjusting them so they look correct for display. the easiest way to tell is if you open up your HDR in Lightwave. If it looks horribly dark then it's... in 1.0 gamma.

Likewise if you are rendering in Linear mode, you need to adjust all lights and luminance values to compensate... I found this when I moved over, using luminous polygons to light with: I had to increase their brightness by POW 2.2 because when the image is gamma corrected both their luminance and their reflections are darkened. I hadn't noticed with lights so much as I normally use an 100% white light which needs no adjustment :D

[toby]

Do you mean you're gamma correcting HDR light probes??? If so, DON'T do that!!!!! They need to be left linear!

Of course not, but a lot that you find on the web that are already, for use with sRGB workflows that most people are still using. Just wanted to warn people that increasing the gamma will actually decrease values that are above 1.


In order to display a linear image on screen, it needs to be encoded down to 8-bit. To understand what needs to happen, think of it in this way. Imagine you have a very large box full of items, this represent our linear image. You also have a much smaller box, this represents an 8-bit image. You want to place all of those items from the large box into the smaller box. Obviously, not all of the items are not going to fit in, you’re going to have to leave some items out. But which items do you decide to leave out?

Well, this is what ‘Gamma Encoding’, or ‘Gamma Correction’ does. It decides which parts to leave out based on what we know about how the eye sees luminance. Simply speaking, Gamma Correction ‘chooses’ the range of luminance values in the linear image data our eyes can percieve changes in, and throws away the rest. The purpose of this whole process is to store linear luminance data in 8-bit format. The fact our eyes only see certain ranges helps make this process possible.

Not quite, a linear image doesn't need to be 8bit to look 'normal', it just needs a gamma curve applied; it's still floating point hdr.

[Matt]

Of course not, but a lot that you find on the web that are already, for use with sRGB workflows that most people are still using. Just wanted to warn people that increasing the gamma will actually decrease values that are above 1.

Exactly, because the data is being encoded down, so high (and low) values will be lost.

Not quite, a linear image doesn't need to be 8bit to look 'normal', it just needs a gamma curve applied; it's still floating point hdr.

Yes my statement "In order to display a linear image on screen, it needs to be encoded down to 8-bit" is misleading, you're correct in that you can apply gamma correction to a HDR file, and it will still be 'linear' (but with LDR 'values' packaged up in linear space) it doesn't _need_ to be 8-bit to look correct.

[toby]

Exactly, because the data is being encoded down, so high (and low) values will be lost.

Yes my statement "In order to display a linear image on screen, it needs to be encoded down to 8-bit" is misleading, you're correct in that you can apply gamma correction to a HDR file, and it will still be 'linear' (but with LDR 'values' packaged up in linear space) it doesn't _need_ to be 8-bit to look correct.
You can still have HDR values after gamma is applied, the gamma curve only changes the data, doesn't get rid of it. Getting rid of data requires a 'clamping' of the image.

The blue dots here are at 0 and 1, above and to the right are the values above 1, they're still above 1 when the gamma is applied

[Tobian]

Yes good example Toby, hence when you are working in LCS you need to adjust all lights and luminous surfaces with the 0.4545 gamma (or Pow of 2.2) so that makes them darker below 100% and brighter above 100%

(attached) as you can see, with a scalar value of 3 it's transformed to a value of 11.2116 - which means you'd need to set luminous surfaces which had been 300% up to 1121% - as you can see by transforming the Gamma to 2.2 (Pow 0.4545) a value of 300% would be transformed to only 164%

Sometimes you have to do it by eye though, as obviously the lighting will be totally different under LCS, but previously where my Luminous surfaces used to light interior environments used to be about 3-400% - they are now 750-900%

[toby]

Yes good example Toby, hence when you are working in LCS you need to adjust all lights and luminous surfaces with the 0.4545 gamma (or Pow of 2.2) so that makes them darker below 100% and brighter above 100%

(attached) as you can see, with a scalar value of 3 it's transformed to a value of 11.2116 - which means you'd need to set luminous surfaces which had been 300% up to 1121% - as you can see by transforming the Gamma to 2.2 (Pow 0.4545) a value of 300% would be transformed to only 164%

What a handy little node! Thanks for pointing that out (and how to use it)

[Tobian]

Hehe, np, I think I got that from Gerrardo :)

The weird thing I just noticed is that there is a slight discrepancy from the output of all those nodes (a gamma function node, sg colour correct node, simple colour corrector and a function gamma node) and what *should be the correct value: Photographers have used for years what is known a an '18%' bright card, to get an accurate exposure and balance of light in the scene, because 18% corresponds to 50% perceptual luminance... Except with Gamma 2.2 it's actually closer to 22% :D I recall Gerrardo mentioning that the sRGB calibration is a slightly modified 2.4 gamma curve with a customised response curve (so a more complex LUT than simply deriving the POW/Gamma response) and yes, with a gamma of 2.4 - 50=18 so it seems to be the case. But it's probably best to stick to 2.2 since most modern computers are calibrated as that, and even Mac's have now built their colour calibration round 2.2, so they match PC's now :D (well ish hehe)

[tudor]

I use Gerardos LSC setup using DP nodes.
One stop fix that does not require you to gamma correct any textures or light colours you use.
Once you have that setup saved as a preset you can add lsc in a matter of seconds to any scene.

[Matt]

That input spy node is handy, where's that from?

[Lightwolf]

That input spy node is handy, where's that from?
LWPluginDB is your friend:
http://www.lwplugindb.com/Plugin.aspx?id=c793077b
(By Ken himself).

Cheers,
Mike

[Tobian]

I use Gerardos LSC setup using DP nodes.
One stop fix that does not require you to gamma correct any textures or light colours you use.
Once you have that setup saved as a preset you can add lsc in a matter of seconds to any scene.

That would involve understanding what Gerrardo says, which I don't a lot of the time :D It's kind of hard to follow what he's doing sometimes! Also, as I recall, he said the results aren't exactly the same if you just colour adjust your colour by his settings, but I can see the appeal :)

and yeah input Spy is very handy, I'm using it in my upcoming video in 3D world magazine :)

[Waves of light]

Matt,

Thank you very much for that video. I can't believe the difference between the standard render and the gamma corrected render.

Thanks for sharing.

[zardoz]

my only question is: we can only see the gamma adjusted render in the end right? what I mean is, I understand using a linear workflow and I use it most of the time, and I export to exr; but in LW in the render preview I can't see it with the gamma applied right? LW only applies the gamma in the end right? (for previewing purposes only).

[Matt]

my only question is: we can only see the gamma adjusted render in the end right? what I mean is, I understand using a linear workflow and I use it most of the time, and I export to exr; but in LW in the render preview I can't see it with the gamma applied right? LW only applies the gamma in the end right? (for previewing purposes only).

In LightWave 9.6 Gamma is added after rendering by the FP_Gamma plugin (which obviously you need to add) in the 'Image Processing' panel.

But if you're rendering to EXR, then you don't want to apply Gamma inside LW at all, because that will then Gamma adjust the EXR file (which I imagine you'd want to leave Linear).

Within LW 9.6 there is no way I know of to leave a HDR / EXR linear, but Gamma adjust the final Render Preview (or even just Gamma correct a plugin like .PSD saver).

LightWave HC (but not LW 9.6.1) however has new LWF capabilities, which allow you to see Gamma Correction in the Render Preview window but will allow you to save to HDR / EXR in Linear space.

[toby]

Matt,

Thank you very much for that video. I can't believe the difference between the standard render and the gamma corrected render.

Thanks for sharing.
Well, the reason it's a big difference is because it had already been gamma'd down into linear color space before he gamma corrected it. In a linear workflow, the render will always look much too dark, until the gamma 2.2 is applied.

[Lightwolf]

Within LW 9.6 there is no way I know of to leave a HDR / EXR linear, but Gamma adjust the final Render Preview (or even just Gamma correct a plugin like .PSD saver).
Not natively. exrTrader has a display gamma setting, and that can optionally be applied after exrTrader has worked on (and saved the buffers) - which is when LW will get the final render for the Preview/Image viewer.

Cheers,
Mike

[toby]

LightWave HC (but not LW 9.6.1)
Damn. I assume you don't get HC without buying core - not planning on upgrading

[zardoz]

LightWave HC (but not LW 9.6.1) however has new LWF capabilities, which allow you to see Gamma Correction in the Render Preview window but will allow you to save to HDR / EXR in Linear space.

This is the answer to my question. My problem isn't with the linear workflow itself, it's with the fact that when I'm rendering I want to have a preview of the render with a gamma applied (or else we're looking at a dark render). I don't want to wait two hours for a render and then only in post find that something is wrong when I apply a gamma.

I ask this because I see my workmates rendering in xsi (mental ray) and max (vray) and they see the render with the gamma already applied while previewing, and then they save the linear exr or wahtever.

And sometimes I tend to not use a linear workflow, because I usually don't let a render finish, when I'm texturing or just testing stuff. So there's no way I can preview how a render will look like with the gamma applied.

tx for answering, good to know that future versions have this fixed.

[Matt]

Damn. I assume you don't get HC without buying core - not planning on upgrading

Nope, I guess it's part of the carrot.

[Lightwolf]

This is the answer to my question. My problem isn't with the linear workflow itself, it's with the fact that when I'm rendering I want to have a preview of the render with a gamma applied (or else we're looking at a dark render). I don't want to wait two hours for a render and then only in post find that something is wrong when I apply a gamma.
You can use the colour correction pixel filter that's a part of the free db&w Tools for that.

Then apply a colour correction image filter after that (with 1/gamma as the gamma setting) to get rid of the gamma prior to saving in a linear format.

Cheers,
Mike

[zardoz]

is this a node or a pixel filter? (ok I see it's a pixel filter too)
I'm checking it right now

[Lightwolf]

is this a node or a pixel filter? (ok I see it's a pixel filter too)
I'm checking it right now
Yeah, it's the same basic code, but available as a node, image filter and pixel filter.
Just in case ;)

As a nice side effect, if you use the pixel filter then the calculation of the adaptive sampling threshold will be based on the gamma corrected image (which was the initial reason to create it).

Cheers,
Mike

[Soth]

Then apply a colour correction image filter after that (with 1/gamma as the gamma setting) to get rid of the gamma prior to saving in a linear format.

I am wondering, is that lossless?

Why everybody is making tutorials about stereo rendering and no one about linear workflow? What is more useful I ask! :)

[Lightwolf]

I am wondering, is that lossless?

More or less, within the precision constraints of 32bit float numbers.

I'd say for practical purposes: Yes.

Cheers,
Mike

[zardoz]

thanks so much for this tip and plugin mike, that's exactly what I wanted.

I see that the gamma is applied after the radiosity calculation, I guess it can't be done before. It's great, I'll use a linear workflow more often now thanks to your plugin and tip.

[richdj]

Cheers Matt. Need to have a play later..

Rich

[richdj]

Hey, just wanted to say this has been a great inspiration.. Re-visited an old interior and rendered with minimal lighting (sunlight and window light, both area's, and FG), and of course the gamma reduction. Then a quick 'save as' to .exr file and bang, it's done what I've been wanting it to do... Also, had a play with 'levels' on a standard .jpg render, and that's working fine... Now, I must go through the rest of the thread...

Cheers again..

Rich

[Disciple]

BTW: I'm gonna do an update to the video, as I made some incorrect assumptions as to what Gamma is and why Gamma Correction exists. Another small correction, please. :)
The "signal" and "intensity" axis labels on the little graphs (pages 5-8) ought to be swapped.

Good work on this. I just received the link today.

Glory to the Almighty!
Disciple

[Zafar Iqbal]

Top notch explanation, Matt. Just saw this thread now.

I literally stumbled upon LWF some 2 years ago, when I was doing some research about Gamma and shortly after saw this thing called Linear Workflow - Funny thing is that I can't even remember why I was researching about Gamma.

Both subjects were confusing - partially because mixed quality of material on the subjects (some being completely off), but also because I was too used to the old ways (look rather).

Discovering LWF was the best thing happening. No longer did I have to set up lighting by trial and errors over and over again - it's so much more predictable now.

Some interesting info I read while researching all this back then: Gamma was introduced to tellies to save energy, and thereby make them more appealing to the consumers. Whether or not it's true.. well, I really don't care - Gamma is evil and should die :)

[Matt]

Another small correction, please. :)
The "signal" and "intensity" axis labels on the little graphs (pages 5-8) ought to be swapped.

Well spotted, yes, they are the wrong way around! How did I miss that! :D

[akademus]

I use Gerardos LSC setup using DP nodes.
One stop fix that does not require you to gamma correct any textures or light colours you use.
Once you have that setup saved as a preset you can add lsc in a matter of seconds to any scene.

Where is that setup. I cant seem to find it? I've read his article back in HDRi magazine, but little I understood then.

[Brötje]

Yeah, great work!

Just one question. How can you degamma an image? Do you need to do that in Photoshop or is it something that has to be done in Lightwave internally?

[Tobian]

If you want to do it in an external application, you will have to convert them first to a 32bpp format, then de-gamma them, and then save them as an HDR or EXR or other 32bpp format LW can use... Otherwise you will get horrible banding problems, and colour quality loss.

If you do it within LW, in the node editor, that'll work in 32bpp internally, so you won't get banding issues. Either use the 'simple colour corrector' node set to gamma 0.4545 http://www.db-w.com/content/view/137/ Or you can use the SGCC node http://www2.informatik.hu-berlin.de/~goetsch/CCTools/ with the input set to sRGB and the output set to Linear.

There's some other examples and explanations in the lightwiki page http://www.lightwiki.com/SG_CCTools_-_For_Color_Management_and_Linear_Workflows

[Matt]

Yeah, great work!

Just one question. How can you degamma an image? Do you need to do that in Photoshop or is it something that has to be done in Lightwave internally?

I use this method:

1 / TARGET GAMMA (usually 2.2) using the FP Gamma plugin in the Image Editor.

[Tobian]

matt, the problem with doing any colour transforms in the image editor - is it only transforms them in the colour space they are saved in.. aka if you have an 8bpp image, then it will do a colour transform, and re-save out a 8bpp image as a temporary file, for your use...

It'll be more noticeable on images with subtle gradients and such, but I have done colour transforms in the image editor and noticed banding issues.

[Matt]

matt, the problem with doing any colour transforms in the image editor - is it only transforms them in the colour space they are saved in.. aka if you have an 8bpp image, then it will do a colour transform, and re-save out a 8bpp image as a temporary file, for your use...

It'll be more noticeable on images with subtle gradients and such, but I have done colour transforms in the image editor and noticed banding issues.

That's good to know, I did wonder, especially as using FP Gamma might give the impression that it's doing it in Floating Point space, might as well use the Gamma setting on the 'Editing' tab.

In fact, is there a difference?

[Tobian]

the colour transformation is being done in floating point space, but the image is resampled in 8 bit again, for output. Anything done within the node system is all handled in 32bpp/float space. I believe anyway, I could be wrong :D

I doubt there's a difference at all. Still only way to find out.. test it.. Colour process an image and then see if it looks banded. One test I did showed it did, but that was using the gamma setting in the editing tab....

[hansen]

I am sorry but...so you do something to the images that you use as textures. Than you set something in LW to make them look normal again for viewing after render. I can tell that everyone else here is getting this, but it is the first that I have ever... EVER! heard of this and all I keep reading (and seeing in the beginners video) is blah blah blah gamma. The way you all are throwing around the terminology and post gamma 2.2 this and divide by your output devise that I just don't think this is a beginners area. What do you do? And when do you do it? Lets say I have the scene of the room from the video with the wood floor. Good. To get to the nice room at the end of the video, what do I set and how do I set it? Or, if that is too much to ask than for instance
just in photoshop, how do I make the texture gamma neutral on the floor?

[toby]

I am sorry but...so you do something to the images that you use as textures. Than you set something in LW to make them look normal again for viewing after render. I can tell that everyone else here is getting this, but it is the first that I have ever... EVER! heard of this and all I keep reading (and seeing in the beginners video) is blah blah blah gamma. The way you all are throwing around the terminology and post gamma 2.2 this and divide by your output devise that I just don't think this is a beginners area. What do you do? And when do you do it? Lets say I have the scene of the room from the video with the wood floor. Good. To get to the nice room at the end of the video, what do I set and how do I set it? Or, if that is too much to ask than for instance
just in photoshop, how do I make the texture gamma neutral on the floor?

To put it very simply:

1. untreated digital images do not look right to the human eye.*

2. to make them look right to the human eye, the "midtones" are brightened.**

3. brightening an image for human eyes makes it inaccurate for the renderer to use. So the process to get more accurate renders is to remove the brightening before rendering. Afterwards the rendered image will need to be brightened again, for viewing.


* this is because human eyes don't percieve light in a linear fashion. If you look at a light source, then drop the lights' power in half, it will not look half as bright.

** This has been done to virtually all digital images you'll find. Gamma, usually with a value of 2.2, is what is used to brighten the mid-tones. Values above 1.0 will brighten, values between 1 and 0 will darken.


Is that clear so far?

Most importantly, don't feel obligated to learn the Linear workflow at all!! No one is going to look at your renders and say "yuck, he didn't use a linear workflow". Mind-blowing images are entirely possible without it, and it won't make the difference between so-so and incredible work.

[kyuzo]

Ha ha.. Don't worry Hansen, you're not the only one.

I have only just 'got it'. I had looked at Matts PDF (which explains what gama is), but I really needed a simple 'do this, do that' instruction. (which IS actually in his video tutorial that goes with the PDF, which I wish I'd viewed ages ago.)

With the latest issue of 3D World having a 6-page feature on gamma and linear workflow, I thought I'd take another look. I thought I'd figured it out, but confirmation really came NOT in the linear /gama article, but in one line Tobian wrote in his pluto station article...

"Essentially you remove the display gamma from the textures and colours used in all the materials: apply a gamma of 0.4545 (the inverse of gamma 2.2). Then after the render, apply a display gamma of 2.2 again."

Like Tobian and, I'm sure, many others, I use db&w's simple colour corrector node to de-gamma my textures.

Derek

[Sampei]

Matt thanks a bunch for the PDF, I didn't even know what gamma theory was. Great stuff for noobs like me ! :thumbsup:

[Matt]

Matt thanks a bunch for the PDF, I didn't even know what gamma theory was. Great stuff for noobs like me ! :thumbsup:

Ahh, well, that PDF has some errors in it, I need to correct it, but errors aside, it still helps I think.

[Tobian]

Haha, yeah there's the theory, and it's scary and full of numbers, and there's doing it, which is what I was trying to show in my tutorial. It's just REALLY hard to be concise about the subject, as it's complex to explain WHY you need to, though not always that complex to explain what to do, but there's never 1 good way to do it :) All of them have flaws complexities and issues.

One thing I find is very confusing, and confused me quite a lot early on, is the difference between the gamma transform which is being done, the intent, and the inherent gamma of the image... The input and the output... For example, If you want to take a standard sRGB image and transform it to be linear, you apply a gamma curve of 0.4545, you de-gamma it (yes that's not a real word LOL). That is the actual transform which is being performed... However many colour management systems in software ask you 'what is the gamma of the image' - to which you reply 'It's in 2.2 gamma space' - the system then works out that the image needs to have a inverse gamma of 0.4545 applied. This confuses things a lot because it flips the numbers in your brain if you know what you want to do vs what the system is asking you for...

The SG colour tools were out before the DB&W tools, and they are very cool, but are a bit 'what does all that mean' haha :)

The other thing which really stumps a lot of learners, and definitely me, was when you work in Linear Gamma colour space you need to mess with everything to make it work properly, and even if you use a very simple software switch to alter everything, things which looked fine in a regular render, look horrible in LCS. Basic stuff like the ambient light, or how you layer complex shaders can look REALLY wrong in LCS. I think the first full experiment I did in LCS was making a car-paint shader, and I got some basics wrong, which looked fine in my normal renders, and looked really horrible and wrong in LCS, it really threw me till I figured out what I was doing wrong, which involved many hours of experiments... All that said there is light at the end of the tunnel, once you 'get it' it's fairly easy to keep doing it afterwards, and it hardly takes me any time to balance everything for LCS now! :D

hope you get a chance to look at my tutorial Matt, it might help you out?

[Lightwolf]

For example, If you want to take a standard sRGB image and transform it to be linear, you apply a gamma curve of 0.4545, you de-gamma it (yes that's not a real word LOL). That is the actual transform which is being performed... However many colour management systems in software ask you 'what is the gamma of the image' - to which you reply 'It's in 2.2 gamma space' - the system then works out that the image needs to have a inverse gamma of 0.4545 applied. This confuses things a lot because it flips the numbers in your brain if you know what you want to do vs what the system is asking you for...
To make it even worse, if you apply a gamma of, say, 2.2 in code, then you're actually raising the value of the pixel to the power of 1/2.2, which is 0.4545 :D

Mathematically it's:
output = input^(1/gamma)
(^ should be: to the power of..., i.e. x^2 is x squared).

Just as a bit of trivia to add even more to the confusion ;)

Cheers,
Mike

[Tobian]

Yeah I noticed that LW, as if you use the POW node in LW with a value of 2.2, it applies a 0.4545 gamma transform, which was one of the ways to do it before your SCC node came along :D

I changed over at just the right time, as a whole bunch of tools, like the SCC came along at that time, to make the transition a LOT easier! :D

[phillydee]

Ahh, well, that PDF has some errors in it, I need to correct it, but errors aside, it still helps I think.

Matt over the years you've been one of the most unselfish folks here on the NT community--just your time to help explain the linear workflow really speaks volumes.

Thanks again. BTW It still helps :thumbsup:

Peace.

[Matt]

Matt over the years you've been one of the most unselfish folks here on the NT community--just your time to help explain the linear workflow really speaks volumes.

Thanks again. BTW It still helps :thumbsup:

Peace.

Why thanks, glad to see it's noticed! What can I say, I like to share! :)

[Oedo 808]

Why thanks, glad to see it's noticed! What can I say, I like to share! :)

Got any spare cash floatin' around guv'na?

[Matt]

Got any spare cash floatin' around guv'na?

Sure how much do you need?

:D

[Oedo 808]

Sure how much do you need?

:D

Very kind of you Sir, I just need enough for a pack of fags, a sixpack of Super T's and the Daily Sport, oh and I'll add a EuroMillions ticket to that as well, that way I can pay you back if I win.

;D

And thanks for the tips, I am curious about understanding gamma correction and linear workflow, so I will be looking into your work, but right now I think I'd need a sixpack of Super Tennent's before even approaching the subject. Cheers!

P.S. Also, an i9 system with a H50 cooler would be nice when the time comes.

[Matt]

Very kind of you Sir, I just need enough for a pack of fags

Well, I bet that statement has just raised an eyebrow for our US cousins!

:D

[Tobian]

Hmm they come in packs now.. Yeah that is indeed worrying :D

[RudySchneider]

Well, I bet that statement has just raised an eyebrow for our US cousins!:D

Only those who are too inept to know otherwise...

[cagey5]

ok. In that case I should point out my rubber's just about worn out. I've been using it for about 18 months and it's looking a bit frayed at the edges. Hopefully that travels ok too. :)

[Oedo 808]

Matt, forgive me for derailing the thread.









P.S. I've never wrapped my lips around a fag, though I admit I've been tempted.

[phillydee]

not all your US cousins are clueless... :D

[cagey5]

ok Getting the thread back on the rails. I too have had some trouble getting my head fully around the concept of something I had never thought about nevermind dealt with before. So I dragged in an old scene that contained various elements that would be affected by the gamma changes discussed. I'll discuss the changes I made to accomodate my understanding of linear editing. Note these assumptions are probably wrong, hence this post.
Image One is the original output. Looking at it now it does look quite 'contrasty' but it is my starting point.

Now my assumption is that this image should really have gamma correction applied to it in order to display correctly on monitors.

Image Two. - I have changed the viewer CS setting to sRGB from Linear. And am therefore seeing a gamma corrected image? Obviously this looks washed out because the original render was effectively too light.

Image Three - I modified all the images used for textures (wood and sky) to be sRgb, which made them darker in the final image.

Image Four - I modified the CS setting for '8 bit files' from linear to sRGB but I don't know why other than it made the final image slightly darker.

After that I'm at somewhat of a loss. Changing 'palette files' from linear to sRGB has no discernable effect so I am then left to adjust the lighting? % G.I.? individual colours? to try and get a decent looking final image.

Adjusting the actual colours seems to have the best overall effect but that would seem to mean going back and adjusting every colour value in the scene from the lights, the base colour for all the wooden items, the node elements for the sea and most significantly the colours for the graduated backdrop which seem to end up unrealistically dark and far from the default values.

Even then the final image appears flat and washed out compared to the original. So I guess some of my assumptions are wrong and I'm going seriously adrift or past scenes cannot easily be modified to get them back 'linear' and it's something I need to build in to future scenes.

As always, any input gratefully received.

[Lightwolf]

Changing 'palette files' from linear to sRGB has no discernable effect so I am then left to adjust the lighting? % G.I.? individual colours? to try and get a decent looking final image.

Yes, all three of them actually. In general you'll need to light darker than you're used to. However, this also means that the inverse square light falloff (which is how light behaves in the real world) will behave correctly.

Cheers,
Mike

[Tobian]

Ok slightly confused.. where are you changing these settings, is this LWHC colour settings, as erm you shouldn't be posting that in here LOL

Couple of things to note about LCS though...

1) sometimes you're not getting a huge amount out of it, especially if your render already looks good as it is... It's a bit less noticeable in outdoor scenes.

2) don't expect your renders to look the same only better. Sometimes LCS makes something look quite a bit different than you might expect. Sometimes this is because your settings are wrong, but sometimes it's just your expectations are, cause you're SO used to sRGB rendering!

3) You need to adjust all textures (colour, not diffuse /spec/ref) and colours in the SCENE. This includes things like environments, environment colours, ambient light colour and light colours. You also need to alter the intensity of all lights with a gamma modifier, including ambient light.. Remember a 5% ambient light value, gamma adjusted = 25% !!! Even 1% = 12% - those are high values to have for ambient lights! :)

and yeah as Michael says, you just need to re-light because light is working in a much different way in a lot of cases, so your old renders can look really ODD! :)

[probiner]

inverse square light falloff (which is how light behaves in the real world) will behave correctly.
And when it does... oh man...

[toby]

After that I'm at somewhat of a loss. Changing 'palette files' from linear to sRGB has no discernable effect so I am then left to adjust the lighting? % G.I.? individual colours? to try and get a decent looking final image.

The un-corrected images are not for judging the image at all. De-gamma the colors for the render, then add the gamma back (the same amount you used to de-gamma) before judging the image. De-gamma/linear color is *only* for accurate math in the renderer.

If it looks washed out, that means you've added 2.2 gamma redundantly - you never want this.

[Matt]

Think of images and colours as using unsalted butter in cooking.

No extra salt comes from the butter (de-gamma'd images and colours) but you add salt to taste after (add gamma).

Whereas using salted butter (gamma'd images and colours) and adding salt after (adding gamma) means it will be too salty!

Gamma is the salt in 3D! :D

[Tobian]

Hehe good analogy, though sadly analogies don't tell you what settings to alter :D

[cagey5]

Yes, all three of them actually. In general you'll need to light darker than you're used to. However, this also means that the inverse square light falloff (which is how light behaves in the real world) will behave correctly.

Cheers,
Mike

Thanks, I'll keep experimenting

Ok slightly confused.. where are you changing these settings, is this LWHC colour settings, as erm you shouldn't be posting that in here LOL

Good point, I must admit I'd overlooked which section this thread had initiated in. However, it's no secret that HC has linear CS and has already been discussed several times in this thread, so with Newteks' indulgence, I'll press further, mindful of that fact.

Couple of things to note about LCS though...

1) sometimes you're not getting a huge amount out of it, especially if your render already looks good as it is... It's a bit less noticeable in outdoor scenes.

2) don't expect your renders to look the same only better. Sometimes LCS makes something look quite a bit different than you might expect. Sometimes this is because your settings are wrong, but sometimes it's just your expectations are, cause you're SO used to sRGB rendering!

3) You need to adjust all textures (colour, not diffuse /spec/ref) and colours in the SCENE. This includes things like environments, environment colours, ambient light colour and light colours. You also need to alter the intensity of all lights with a gamma modifier, including ambient light.. Remember a 5% ambient light value, gamma adjusted = 25% !!! Even 1% = 12% - those are high values to have for ambient lights! :)

and yeah as Michael says, you just need to re-light because light is working in a much different way in a lot of cases, so your old renders can look really ODD! :)

I think you're right in that I am very used to seeing sRGB renders and I need to rethink my approach using linear CS.
I tried taking ambient down to 0% from the 5% initial value with very little noticeable affect, so I'll re-visit the main lighting and GI percentage too.
btw. It's not important for me to get a match to the original image it's just an exercise for me to try and implement some of the techniques discussed so as to better understand them.

The un-corrected images are not for judging the image at all. De-gamma the colors for the render, then add the gamma back (the same amount you used to de-gamma) before judging the image. De-gamma/linear color is *only* for accurate math in the renderer.

If it looks washed out, that means you've added 2.2 gamma redundantly - you never want this.

This seems to be the point I am at. How do I de-gamma the colour? I've seen a couple of posts in this thread referring to various third party plug-ins and alternative colour pickers.
Is there nothing in LW or more specifically HC that will allow me to do that?

Think of images and colours as using unsalted butter in cooking.

No extra salt comes from the butter (de-gamma'd images and colours) but you add salt to taste after (add gamma).

Whereas using salted butter (gamma'd images and colours) and adding salt after (adding gamma) means it will be too salty!

Gamma is the salt in 3D! :D

Nice analogy. I seem to be working with a partially seasoned image at this point in that I've taken the gamma out of the included images but not out of the colours. Still struggling with that one.

[probiner]

Honestly i find gamma easier to understand than DPI... Try to use salt on DPI... :D

(not to control of course, gamma makes more head twists =P )

[Tobian]

Ok so some crystals of salt are bigger than the others... Hang on you what.. You're one of those?

GET OUT!!!

:p

[cagey5]

Honestly i find gamma easier to understand than DPI... Try to use salt on DPI... :D

Apparently it's all to do with the size of the grains of salt you're using. ;)

[edit] Beat me to it.

[probiner]

The hard part is to make the salt a conversion rate but keeping the same proportion with the other two =P

Lets say you have a guy with high blood preassure. Everyday, he eats soup (pixels) made by his wife. She does not put the same salt (DPI) everytime she makes the soup. So his life expectancy (document size) is a russian roulete.

- So if his wife put more salt (DPI) in the same usual amount of soup(pixels), the guy will live less (document size). (300 grams of salt? :D)

- If she makes more soup but uses the same salt amount, the guy will live more.

- If he manages to live a long life and the salt amount was huge and the soup very few, hes a freak of nature (pixelation)

(terrible example i know...)

EDIT: Tobian, tobian... what did they do to you...? You can tell us... You are safe here... :D

[Tobian]

Yes I agree, you don't understand DPI at all :D

That probably means you work in the publishing industry :p

[evolross]

I have a question... I've understood that I could stay in a sRGB workflow if I wanted to, for example using textures straight off the Internet and using standard lights and colors.

Let's say I do that and I get a nice image I'm happy with, again not doing any gamma tweaks that this thread is discussing. Then I export using a floating point file (TIFF FP, EXR, or HDR).

Then I give that to a compositor who's compositing in Nuke (a full 32-bit linear compositing package). If that compositor were to use it with no extra gamma or exposure/color tweaks applied, would this be okay?

If I understand correctly, the bad news would be if that compositor started tweaking the image with gamma, color, exposure, etc, then the texture-images and colors in the image would not behave correctly with the lighting of the image because they would all already have 2.2 gamma baked into them. What exactly would go out of whack?

I guess I'm confused to how the lighting of the image isn't related to the colors and image-textures and how they're not all connected in a final image? If I save out in full-precision and am happy with my render result using an sRGB workflow, what is the issue? Especially if I tell my compositor that the gamma is already in the image.

I guess it boils down to this question: What is the difference in using an sRGB workflow, rendering and exporting in FP, and not adjusting gamma in post versus turning all the lights, images, and colors down, rendering and exporting in FP, and then applying gamma in post? Something to do with realistic lighting falloff?

[Zafar Iqbal]

I have a question... I've understood that I could stay in a sRGB workflow if I wanted to, for example using textures straight off the Internet and using standard lights and colors.

You can use them straight off in the sense that you don't have to open Photoshop to convert them. Do that in the 3D app - I haven't touched LW for a long time, so I'm not sure what the options are these days - hopefully you can automate it, in which case: no excuse to try and sneak past linear workflow! :P


Let's say I do that and I get a nice image I'm happy with, again not doing any gamma tweaks that this thread is discussing. Then I export using a floating point file (TIFF FP, EXR, or HDR).

Then I give that to a compositor who's compositing in Nuke (a full 32-bit linear compositing package). If that compositor were to use it with no extra gamma or exposure/color tweaks applied, would this be okay?


No (floats doesn't have gamma btw). You have still made a render while working with a setup that doesn't compensate for the gamma in your monitor (and the textures). Its very much like working while having sunglasses on - or perhaps even 2 pairs of sunglasses on top of each other. You would increase light intensities, color values and whatnot, to make it all look as good as you can through the sunglasses - its the same thing here. Your monitor is causing the render to look darker than it should be. You just donøt know it because thats how you and many other, including me have done 3d for a long long time. Add a display gamma in the 3d app and remove gamma from the textures and you'll be all set.


If I understand correctly, the bad news would be if that compositor started tweaking the image with gamma, color, exposure, etc, then the texture-images and colors in the image would not behave correctly with the lighting of the image because they would all already have 2.2 gamma baked into them. What exactly would go out of whack?


No - they will mess up long before while you are rendering :) The compositor will however exaggerate your wrong doings, but not as much as the rendering process messed them up - depends on how much tweaking is going on in comp ofcause.



I guess I'm confused to how the lighting of the image isn't related to the colors and image-textures and how they're not all connected in a final image? If I save out in full-precision and am happy with my render result using an sRGB workflow, what is the issue?

Especially if I tell my compositor NOT to change the gamma.

You are confused because you are not used to floats. Am I correct? If you render out in float and are already mostly happy with the look, then there isn't much need for you to render in float. Float is much more than that - thy this: Illuminate a scene with 1000 times brighter light than you would normally do. Render out as float and then lower the exposure in comp - that will give you the answers. Oh, this will also clarify why it's important to feed the render engine with gamma 1.0 textures - if you do the render like always that is.

The issue (I assume) is that you have been rendering outside LWF for so long, that you can't "see" all the goodies that comes with LWF. Don't take this the wrong way - It was exactly like that for me, and I was like.. wth? LWF sucks :D but today, I wouldn't go back.

Oh and btw.. you ARE supposed to tell the compositor to change the gamma :P

[evolross]

You are confused because you are not used to floats. Am I correct?
No, I'm familiar with floating point file types and gamma. I'm not doubting the benefits of LWF or trying to resist it, I'm trying to identify what the specific benefit is for my own personal knowledge. I didn't mean to convey a resistance to LWF at all. I'm all for better methods to doing things. I'm just confused still about it.
No (floats doesn't have gamma btw). You have still made a render while working with a setup that doesn't compensate for the gamma in your monitor (and the textures).
Okay, I meant to convey that when the compositor imports my file sequence they would apply an sRGB "import" LUT on my image. So they would then see what I see. So we're all wearing the same sunglasses.
If you render out in float and are already mostly happy with the look, then there isn't much need for you to render in float.
Just because my image has 2.2 gamma baked into it, and the compositor imports it into Nuke correctly, wouldn't it still help my compositor if the values are in a floating point file format? Doesn't that give them much more flexibility to adjust versus an 8-bit TIF?

My point is, if I get a great render using an sRGB workflow (and the compositor knows it's an sRGB image and applies that import LUT) and I save in float, then doesn't the compositor still have a floating point range to work in and shift the image's values around however they need to composite it correctly?

So again, what's the difference in baking gamma into an image using an sRGB workflow versus turning everything down, applying gamma in post using a linear workflow, given that both are floating point export file-types? From what I read, it sounds like it's something to do with accurate lighting falloff. I want someone to confirm that. It seems like every time I ask this question, people answer it what gamma is and what floating point is... I get all that. But what's the workflow benefit and what am I NOT getting in an sRGB workflow IF I like the way my render looks and I export it in FP?

[toby]

No, I'm familiar with floating point file types and gamma. I'm not doubting the benefits of LWF or trying to resist it, I'm trying to identify what the specific benefit is for my own personal knowledge. I didn't mean to convey a resistance to LWF at all. I'm all for better methods to doing things. I'm just confused still about it.

Okay, I meant to convey that when the compositor imports my file sequence they would apply an sRGB "import" LUT on my image. So they would then see what I see. So we're all wearing the same sunglasses.

Yes, rendering to sRGB / float works just fine. Any compositor who's not a beginner (esp. a nuke compositor) should know what to do already.

Just because my image has 2.2 gamma baked into it, and the compositor imports it into Nuke correctly, wouldn't it still help my compositor if the values are in a floating point file format? Doesn't that give them much more flexibility to adjust versus an 8-bit TIF?

My point is, if I get a great render using an sRGB workflow (and the compositor knows it's an sRGB image and applies that import LUT) and I save in float, then doesn't the compositor still have a floating point range to work in and shift the image's values around however they need to composite it correctly?
Yes, the renderer outputs float, you may as well keep it. You can lose a lot of useful data if you clamp all the values at 255 / 16 million colors.


So again, what's the difference in baking gamma into an image using an sRGB workflow versus turning everything down, applying gamma in post using a linear workflow, given that both are floating point export file-types? From what I read, it sounds like it's something to do with accurate lighting falloff. I want someone to confirm that. It seems like every time I ask this question, people answer it what gamma is and what floating point is... I get all that. But what's the workflow benefit and what am I NOT getting in an sRGB workflow IF I like the way my render looks and I export it in FP?

The difference is that textures and color-picker chosen colors (light color) are the only things that get a gamma applied to them. Shading, light falloff and things like a fresnel/incidence angle gradient are always linear. So without a linear workflow, you're actually sending both srgb and linear values to the renderer.

This doesn't 'break' anything, it's been done for years, award-winning stuff has been done this way, and even industry pros can't look at an image and tell you if it was rendered linear or not. But side-by-side, most people would say that the one rendered linear looks better.

[Zafar Iqbal]

Okay, I meant to convey that when the compositor imports my file sequence they would apply an sRGB "import" LUT on my image. So they would then see what I see. So we're all wearing the same sunglasses.


Correct - but linear LUT if you save as float.


Just because my image has 2.2 gamma baked into it, and the compositor imports it into Nuke correctly, wouldn't it still help my compositor if the values are in a floating point file format? Doesn't that give them much more flexibility to adjust versus an 8-bit TIF?


Yah, float is far superior to 8bit and I for one never render out to 8 or 16 bit any more except for test renders and some matte etc. channels. Go for it.


My point is, if I get a great render using an sRGB workflow (and the compositor knows it's an sRGB image and applies that import LUT) and I save in float, then doesn't the compositor still have a floating point range to work in and shift the image's values around however they need to composite it correctly?


Yah, indeed. Just remember: float = linear LUT



So again, what's the difference in baking gamma into an image using an sRGB workflow versus turning everything down, applying gamma in post using a linear workflow, given that both are floating point export file-types?


If they both are rendered out as float, then you can't have one with gamma and one without. But lets ignore float and go along with 8 and 16 bit instead.

The difference would be a bit like having an extra channel. A G channel, for gamma only - so because the gamma is separated from the pixels, you can do a bit more work before you notice banding. Exactly how much one method is better than the other? I don't know, and I wouldn't be surprised if this part is software dependent as well - I never looked deep into it. I'm too happy with floats.

I used to do very very little and limited post work - if things were the same way today, then I wouldn't mind baking in the gamma in either a 8 or 16 bit file - so in a way it can depend on your needs as well. No need to make things more complicated than they need to be.



From what I read, it sounds like it's something to do with accurate lighting falloff. I want someone to confirm that. It seems like every time I ask this question, people answer it what gamma is and what floating point is... I get all that. But what's the workflow benefit and what am I NOT getting in an sRGB workflow IF I like the way my render looks and I export it in FP?

http://cgpov.com/wp-content/uploads/2009/03/stop_gamma_time_pic.jpg

Top render: rendered like your earlier description, and like many many other people have been doing for a long time.

Bottom: Gamma was introduced while working and when the final render was saved (unless it was baked). Lighting was matched accordingly.

What it means in practice (for me - I can't speak on other ppls behalf) :
Lighting is a pure joy now and much much quicker and more predictable to do.

Gamma isn't limited to lighting. What you perceive as 50% gray in a pic downloaded from the web, is closer to 20% gray/black for the renderer. This affects the colors too, so they change - that's why you need to de-gamma textures.

When I was new to LWF I did a lot of rendering with red-ish textures (very close to pure red). Under harsh lighting these turned out as orange. With LWF they remained close to original tone no matter how harsh my lighting got.

[Lewis]

http://cgpov.com/wp-content/uploads/2009/03/stop_gamma_time_pic.jpg

Top render: rendered like your earlier description, and like many many other people have been doing for a long time.

Bottom: Gamma was introduced while working and when the final render was saved (unless it was baked). Lighting was matched accordingly.


Yes this image is best example what happens and what's the BIG difference, especially for lights and most important IES lights.

Only thing confusing on that image (for me) is that top version is called non-linear while in LW that is called "Linear" and bottom is called "sRGB" (in LW) while here is called Linear-sRGB :). Seems opposite in naming scheme.

[Tobian]

Well to tell you what you're missing out on other than 'good looking renders'. If you're working in sRGB colour space inside the compositing app, but using a float file, there's not normally a huge amount of difference, it's only in a certain number of specific cases you will benefit more from linear over sRGB...

Because the gamma curve affects above the visible gammut line (above 1/white) then anything where the values of those are important can become drastically effected... One classic example would be motion blurs. things such as visible lights can be thousands of % above 100% bright and so give big fat wide smears on the motion blurs. If the luminosity values of LW images are translated using the gamma curve, then that data is effected, so it can result in 'wrong' colour/light smearing.

Likewise things like blurs, glows or bokeh effects from DOF can become dramatically transformed by working in the LCS colour space over sRGB. Yes working in float means these effects work better than working in 8 / 16 bit.. but the results you get in terns of light response matches more realistically what you see in film if your base images are in LCS format.

Beyond that, yes, there are loads of other reasons for working in float, which become most apparent in interior scenes, or scenes where you have near-surface lights, such as spots or windows etc. It both helps you get more realistic light falloff, as the examples show, but almost as important, mitigate blow-out, because as mentioned before, values above 1.0 get lowered as the 2.2 gamma lut is applied.

Bottom line is if you're getting good looking images without using Linear, and you aren't doing stuff like motion blur/bokeh/DOF/bloom etc, then you probably don't really need to change anything, but I still recommend you try it just to get the other lighting benefits.

[Zafar Iqbal]

Only thing confusing on that image (for me) is that top version is called non-linear while in LW that is called "Linear" and bottom is called "sRGB" (in LW) while here is called Linear-sRGB :). Seems opposite in naming scheme.

Lol, yah - it is. I didn't pay attention to the text when I found it. I don't think it will clear up any time soon - a bit like 32 bit colors in Windows/desktop... pfffft :cool:

evolross: I found some test renders I did some time ago, to better understand what happens with the different workflows. See attached.

The renders are supposed to match each other - I didn't spend ages on them and few things could perhaps have been done a bit better - but not much IMO.

Top: LWF
Buttom: The ol' fashion way - no consideration for gamma at all.

Both have somewhat harsh lighting going on and this shows the bottom render is eager to escape from the original red tone.

I've also attached the texture as reference.

So, even if you keep doing renders like you do and then rely on float to do post tweaks, orange wont magically turn back to red.

[evolross]

Shading, light falloff and things like a fresnel/incidence angle gradient are always linear. So without a linear workflow, you're actually sending both srgb and linear values to the renderer.

Top render: rendered like your earlier description, and like many many other people have been doing for a long time.

Bottom: Gamma was introduced while working and when the final render was saved (unless it was baked). Lighting was matched accordingly.


Likewise things like blurs, glows or bokeh effects from DOF can become dramatically transformed by working in the LCS colour space over sRGB.
:bowdown:
Thanks guys, all of that really helped and clarified the "value added" in using a linear workflow. Thanks for responding. I plan to switch over to the LCS workflow ASAP. I also realized I had a copy of HDRI 3D Issue 18 and I read Gerardo Estrada's LCS Workflow article. I had read this years ago in 2007 but then it made absolutely no sense. The article backs up everything you guys said.

It does seem odd to me that this has just now entered the 3D zeitgeist in the last few years, given that it's been a render flaw (for lack of a better word) for so many years.

I'm still confused about something, it seems like different people have different understandings of what a linear image sequence and what is a log image sequence. Different people I've talked to seem to use the terminology in a opposite fashion, thus confusing me. So my question is, if I have a VFX plate in the form of a DPX sequence taken from a camera... is that a linear image sequence or a log image sequence if I were referring to it in that way? And then if I add a gamma LUT to that to view it on my screen, is that "linearizing" or "log-ifying" it (sorry :))? It seems like the raw camera sequence would be a "linear" sequence since that is explained as what we want to work with in our "linear workflow"... right?

Lastly...

Correct - but linear LUT if you save as float.
Yah, indeed. Just remember: float = linear LUT
If they both are rendered out as float, then you can't have one with gamma and one without.
I think you're incorrect on this. Just because you export in FP, doesn't mean you apply a linear LUT. If I'm working in the sRGB colorspace and I export in FP, you would not apply a linear LUT in post. You would use an sRGB LUT. If you apply a linear LUT it will not match Lightwave's render view. Try it yourself. Saving sRGB in FP is still useful because it allows a compositor more range if they're shifting values around to match a plate in a VFX shot for example.

[Zafar Iqbal]

I think you're incorrect on this.

You are right. I did mean to write sRGB, but managed to put down "linear". My apologies.

[toby]

Top: LWF
Buttom: The ol' fashion way - no consideration for gamma at all.

Both have somewhat harsh lighting going on and this shows the bottom render is eager to escape from the original red tone.

I've also attached the texture as reference.

So, even if you keep doing renders like you do and then rely on float to do post tweaks, orange wont magically turn back to red.
That's an example of the reflection fresnel being linear; in the non-linear workflow where you're not adding gamma after the render, the reflection of the white background is too dark because it gets no boost, but the texture did.

[Tobian]

evolross: It's not that it's just entered the 3D zeitgeist, it's that now is the time where we have had access to tools which can deal in floating point colour space period. It's only been a few years since we've been able to edit and manage linear colour files, and that computers could handle them.. it's a huge chunk of extra memory and processing resource to use them properly. It just happens that by good design most render engines work in floating point accuracy, so you can use the workflow ;) That said, also, without the specific working knowledge of the subject, and well designed/easy toolsets for working with them, most people have no clue that their monitor lies to them, why and for what reasons, so it takes a huge effort to convince them to use LCS, because they don't understand they need too :) half the tricks we have to do in compositing / 3d are because of the way computers deal with images, and what they threw away before we got access to the file! :D

Gerrardo can probably answer me infinitely better, but 'log' space is a modified gamma/colour profile, as opposed to a Linear/float, which is by designed a denatured image file.

As a note though, in my (limited) experience, when working in say Photoshop or AE, the software applies a display gamma to the image, so even though it's in linear format, it 'looks' right, whereas LW (v9) Has no display gamma modifiers, so you see the image look 'wrong'. most compositing software has tools which transform the colour profile of the image to match much closer to the response of other mediums, such as film, video, print etc (as they can with 8/16bpp) but because the data is stored in float, you don't suffer loss of data, which can lead to stepping. typically transforming the image to a lower bit depth is/should be the last step of the image/video, much like saving out a JPEG is the output file of your image, not the format you save the project in :D

As toby mentions, Fresnel response curves really only work properly in lcs, which is why you see most people using incidence-angle (straight black->white) style response curves, to boost the strength of the reflection in the mid-range of angle. this yeilds wrong-headed looking reflections. That said 'simple' Fresnels are not exactly what you actually get in most materials, which is why Gerrardo hand-draws his using incidence angle gradients, to more accurately describe Fresnels for specific materials. I believe a lot of this is to do with polarisation, but it starts to go way over my head when I read heavy maths pages on the subject :p So I just use Fresnel nodes, and LCS, and it's 100% better than the oldfi method :D

[StereoMike]

I didn't read the whole thread, just a short question: Is there a 'take-me-by-the-hand' tutorial hidden in this thread? I see the benefits and surely want to give it a try, but I don't even know where to start.

[toby]

I didn't read the whole thread, just a short question: Is there a 'take-me-by-the-hand' tutorial hidden in this thread? I see the benefits and surely want to give it a try, but I don't even know where to start.You could try the video that this thread is about... otherwise, no, it won't 'click' until you learn and understand several things.

[StereoMike]

I saw the pdf and scrubbed through the video, but it only shows why you should do it, not how. I guess it's about these several things then?

[Matt]

I saw the pdf and scrubbed through the video, but it only shows why you should do it, not how. I guess it's about these several things then?

It's pretty easy, I can walk you through it.

[COBRASoft]

Another videotutorial then Matt? Thanks in advance :D

[StereoMike]

Puuuleease, Matt!!!

[Tobian]

Well I did offer to help, but I never got a reply off matt :p

[Matt]

I'll do a quick one. Not been able to do videos for a while because I now have house mates, and doing videos in front of people just makes me feel silly.

But I've not moved my PC into another room, so hopefully things can get back to normal.

[probiner]

I'll do a quick one. Not been able to do videos for a while because I now have house mates, and doing videos in front of people just makes me feel silly.


So funny to hear about that.

At least they might know what you are doing, i have been suprised and even 'answered back' to ppl walking in the street using a bluetooth headset. :D

[Matt]

Okay, here's a quickie tutorial to show how to set up a linear workflow in LightWave 9.6.

Video:
Setting Up a Linear Workflow in LightWave 9.6 (http://www.pixsim.co.uk/video_tutorials/Setting_Up_a_Linear_Workflow_in_LightWave_9_6.zip)
QT H.264 (33MB Zipped)

[Tobian]

Great video Matt, that's quite simple and explanatory :)

There's one main thing you have to be aware of though matt: If you do colour transforms to images in the 'image editor' they are done in the colour space that they are natively in: I.e. if you apply a 0.4545 gamma correction, it will be done in 8bit mode, in 8 bit colour space.. which means that data will be thrown away. If you have a dark texture you'll notice horrible banding issues when the display gamma is re-applied.

To make sure your textures don't suffer from this either save them in a native floating point image format, or do the colour transforms in the node editor, which does it properly in floating point colour space, so no data will be 'thrown away'.

[Lightwolf]

To make sure your textures don't suffer from this either save them in a native floating point image format, or do the colour transforms in the node editor, which does it properly in floating point colour space, so no data will be 'thrown away'.
And ideally you'd want to use a natively linear float image, as that will also create the mip-maps in linear space (which is a downscaling operation that is also affected by gamma).

Once you're in the node editor, those have been created.

Mind you, this is a fairly minor issue except in some extreme cases.

Cheers,
Mike

[Matt]

Great video Matt, that's quite simple and explanatory :)

There's one main thing you have to be aware of though matt: If you do colour transforms to images in the 'image editor' they are done in the colour space that they are natively in: I.e. if you apply a 0.4545 gamma correction, it will be done in 8bit mode, in 8 bit colour space.. which means that data will be thrown away. If you have a dark texture you'll notice horrible banding issues when the display gamma is re-applied.

To make sure your textures don't suffer from this either save them in a native floating point image format, or do the colour transforms in the node editor, which does it properly in floating point colour space, so no data will be 'thrown away'.

Ahhhh yes, I remember talking with Mike about this now, couldn't remember at the time.

[Tobian]

I was messing with a test scene with SIBL recently, and you can see here I'm using the tonemapped backplate.. With the nodes version the colour fidelity is preserved, but with the standard version you can see the stepping and colour fidelity loss in the dark areas. It's actually not that noticeable in this image because of all the contrasts, but if you raise the gamma you can really spot it! :D

[Lightwolf]

Ahhhh yes, I remember talking with Mike about this now, couldn't remember at the time.
How could you with the amount of garbage I intersperse into the juicy bits.

Take this post for example...

Cheers,
Mike

[Matt]

Okay, here's a addendum to the last video.

Video:
Setting Up a Linear Workflow in LightWave 9.6, Addendum (http://www.pixsim.co.uk/video_tutorials/Setting_Up_a_Linear_Workflow_in_LightWave_9.6_v2.z ip)
QT H.264 (14MB Zipped)

[Tobian]

Awesome stuff. Nice and simple. The only other thing to suggest btw, is that the colour of any environment colour/texture should also be colour corrected. DP's sunsky plugin has built in colour space, so that's really handy!

[Matt]

Awesome stuff. Nice and simple. The only other thing to suggest btw, is that the colour of any environment colour/texture should also be colour corrected. DP's sunsky plugin has built in colour space, so that's really handy!

Yay, approval from Tobian! I must be doing something right :)

;)

[Tobian]

Haha oh dear, am I that picky? :D

Well just making sure people know some of the pitfalls of using linear inside of LW. There's another couple of ways to do colour correction inside the node editor, but they involve more nodes.. and there's a general rule of more nodes=longer render time.

[Matt]

Haha oh dear, am I that picky? :D

Noooo, just messing with ya! :)

[nikfaulkner]

thanks a lot matt,

simple and to the point :)

dont suppose you plan on doing anything about render passes using dponts
crazy nodes do you?

i have the hdri3d issues with tutorials and still cant get my head around it, everything i read or see about them are " you can do this, and this....."
not "here's how you do this....."

thanks again


n.

[Matt]

dont suppose you plan on doing anything about render passes using dponts crazy nodes do you?

I've not looked at those ones to be honest.

[Tobian]

Unfortunately that involves translating gerrardo-ese :p Took me some time to figure out what on earth he was going on about with regards to LCS, and I know more about surfacing than compositing apps, so I can't help :)

[zardoz]

Hi Matt, actually I would add another addendum eheh ;)
you used dbw simple colour corrector in the nodes but that plugin pack also comes with a pixel filter, where you can apply the 2.2 gamma and see the results while Lightwave renders, wich is quite useful. You can't see the results while lightwave is doing the GI calculation, but when it starts doing the rest (AA, and other stuff that I have no idea ;)) it already has the pixel filter applied, so you can preview what's happening.

thanks for all your videos.
cheers
LL

[Matt]

Hi Matt, actually I would add another addendum eheh ;)
you used dbw simple colour corrector in the nodes but that plugin pack also comes with a pixel filter, where you can apply the 2.2 gamma and see the results while Lightwave renders, wich is quite useful. You can't see the results while lightwave is doing the GI calculation, but when it starts doing the rest (AA, and other stuff that I have no idea ;)) it already has the pixel filter applied, so you can preview what's happening.

thanks for all your videos.
cheers
LL

Does that one do it in float space like the node one does?

[Lightwolf]

Does that one do it in float space like the node one does?
Yup, the internal buffers are float. They are only converted down either by image savers or the image viewer (and the render preview for viewing purposes).

Cheers,
Mike

[Matt]

Coolness!

[Tobian]

Though as I apparently learned, it makes the AA a little wrong.. Probably not enough to be noticeable, but it also corrects the problem of adaptive sampling not being aware of gamma.

[COBRASoft]

Perhaps all you gamma geeks can make some kind of script for Matt what he has to include in his tutorial :D.

[Lightwolf]

Though as I apparently learned, it makes the AA a little wrong..
...for pretty much the same reason that using a node to gamma correct images is a little wrong.
In the case of images the mip-maps (scaled down version of the original image) are created in gamma, but should be in linear. In the case of AA, the filtering (adding up samples to a final pixel) is done after the gamma correction, which is wrong again.

Cheers,
Mike

[RenderBlur]

So how can we totally avoid these mipmap and AA issues?

I know Matt said it might be tedious -- but if we do convert the 8-bit color images to float beforehand (and I'm guessing I would convert them to something like an EXR using Photoshop?), then apply the 0.4545 gamma, and save the color image. Then when I use it in Lightwave I would skip the degamma Image steps -- would this correct these other problems (mipmap, AA and doing gamma in the right space)?

(and thanks for the videos Matt, I would still be at the first step if I hadn't watched them!)

[Lightwolf]

So how can we totally avoid these mipmap and AA issues?

I know Matt said it might be tedious -- but if we do convert the 8-bit color images to float beforehand (and I'm guessing I would convert them to something like an EXR using Photoshop?), then apply the 0.4545 gamma, and save the color image. Then when I use it in Lightwave I would skip the degamma Image steps -- would this correct these other problems (mipmap, AA and doing gamma in the right space)?

That would get rid of potential mip-mapping issues. Not using the pixel filter to apply gamma gets rid of potential image filtering issues, with the downside that you can't see the gamma corrected render as it renders, and AS computing the threshold not taking the final gamma into account.

Cheers,
Mike

[Tobian]

Yeah it's about striking a compromise. the AS threshold is more of an issue in a lot of cases, rather than the AA issue, as AS affects render time quite a lot!

The ideal would be for AS to be gamma-aware, for colour space to be part of the image loader and mip-mapping to be generated afterwards (though I was pondering if you could make a mip-map node Michael? so it's downstream and therefore correct?) and display gamma in all previewers, would then mean everything was working properly! That's mostly all up to NT (and some of this is in HC)

[Lightwolf]

The ideal would be for AS to be gamma-aware, for colour space to be part of the image loader and mip-mapping to be generated afterwards (though I was pondering if you could make a mip-map node Michael? so it's downstream and therefore correct?) and display gamma in all previewers, would then mean everything was working properly! That's mostly all up to NT (and some of this is in HC)
Well, one could write a pixel filter that, like the one I wrote, gamma corrects the samples which has an impact on the AS threshold but at the same time stores the raw samples and computes filtering on them independently of LW (maybe coupled with an image filter that then takes the filtered pixels and uses them to overwrite the RGBA buffers after the render).
One could also write an image node as you suggested (which is a bit tricky as you'd want multiple instances to share the same mip-maps) - but in a way that's similar to how infiniMap operates.

On the other hand... LW HC has all of the issues solved except for gamma aware AS - so why bother?

Cheers,
Mike

[Tobian]

Fair enough, if NT have implemented a lot of it already then there's no need to bother. With luck they'll also solve the adaptive sampling gamma issue!

[3dWannabe]

I'm having a bit of trouble converting an sRgb to linear from within Photoshop.

From my notes, someone suggested (and I can't find the exact post):

One way to correct textures to linear gamma is to convert them to 16 bit mode, then convert to a linear profile. In Photoshop, you can convert to 16 bit using the menu: Image --> Mode --> 16 bits/Channel. Then convert it to a linear profile (in menu: Edit --> Convert to Profile... then select a linear profile like AIM RGB =Trinitron D65 G1.00

----
However, I don't see that linear profile in Photoshop.

I found instructions for 'making' one:

http://fnordware.blogspot.com/2008/05/making-linear-icc-profile.html

However, I don't see the same dialogs described in CS4 on Win7.

I did try just changing the midpoint in levels to .454545, and that seemed to be close to correct. I was very surprised to find there's no gamma adjustment layer in Photoshop (so I must be missing the reason why, possibly it is tied very strongly to the output profile?).

BTW - I did see an interesting post from Blochi that described using Picturenaut 3 to convert
http://www.hdri-handbook.com/picturenaut/index.html .

-- http://www.hdrlabs.com/cgi-bin/forum/YaBB.pl?num=1255793910/3
you can also use Picturenaut, it will automatically strip the Gamma when you open an 8-bit image, change the Bit Depth to 32-bit, and save it back as EXR. The advantage of Picturenaut is here, that it will keep the Alpha that you may have in a TGA file... whereas in Photoshop that is a lot more work.
--

Maybe that is a possible solution (or it might only generate exrs)? Would be nice to be able to batch convert a number of images and textures (but, that may be impractical as their gamma may not be available or be correct).

[Zafar Iqbal]

However, I don't see that linear profile in Photoshop.


Nevermind it - I personally prefer to take the "linear sRGB profile" route myself.


I found instructions for 'making' one:

http://fnordware.blogspot.com/2008/05/making-linear-icc-profile.html

However, I don't see the same dialogs described in CS4 on Win7.


Perhaps you clicked on the pulldown for the Settings - make sure you click in the "Working Spaces->RGB:" pulldown. If it's already set to sRGB, then pick Custom, and from then on just enter 1.0 in the Gamma field and save with a appropriate name.

[3dWannabe]

Perhaps you clicked on the pulldown for the Settings - make sure you click in the "Working Spaces->RGB:" pulldown. If it's already set to sRGB, then pick Custom, and from then on just enter 1.0 in the Gamma field and save with a appropriate name.

Yes, that was the issue.

Now, I can create an sRGB linear profile. I was able to save it - and load it later. It was named 'Linear sRGB.csf' in appData\Roaming\Adobe\Color\
Settings

However, when I try to 'convert' my 16 bit image to this profile, I don't see the profile anywhere in the list?

So - I'm still stuck? I'm running 64 bit Photoshop CS4 on Win7-64.

Any idea how I can make my elusive profile visible so that I can convert?

[Zafar Iqbal]

Any idea how I can make my elusive profile visible so that I can convert?

You saved the Color Settings using the save button - that's not for the profile itself :)

Click on the RGB pulldown again (after you did the linear thing) - go all the way to the top in the list and you'll see Load RGB and Save RGB options. Those are what you want. The file dialog will point to C:\Windows\System32\spool\drivers\color. Save using a proper filename. You can then either load it, or simply restart Photoshop. PS will auto detect/load any new file from that windows folder - same goes for other apps that support color management.

Note: Make sure to give the profile a name when you created it (the window where you changed the gamma), otherwise you will see it as "Costum RGB", and not like the filename.

[3dWannabe]

You saved the Color Settings using the save button - that's not for the profile itself :)



Yes, that worked!

Now, if I can figure a way to automate it a bit?

BTW - for image sequences that need to be "de-gamma'd", is AE the way to go?

Also, in a previous post I stated "I did try just changing the midpoint in levels to .454545, and that seemed to be close to correct".

Well - it's not correct at all, the colors get washed out doing that, so the "convert to linear" method (after converting the image first to 16 bits), is the way to go!

[Zafar Iqbal]

Now, if I can figure a way to automate it a bit?


Actions are excellent for this. Make an Action and maybe assign a hotkey to it if you plan on using it a lot. You can read about how to work with Actions here: http://blog.epicedits.com/2008/03/07/how-to-create-photoshop-actions/

Basically just do what you would normally do while recording.


BTW - for image sequences that need to be "de-gamma'd", is AE the way to go?

I can't see why not although I've never used AE or any other app to de-gamma. I prefer to do that in the 3d app, and will thereby also save myself from going through this de-gamma step. Maybe it's been debated in this thread in wich case I've missed it, but I personally don't see any reason to de-gamma manually - unless it's easier to do so, than to do it in the 3d app.


Also, in a previous post I stated "I did try just changing the midpoint in levels to .454545, and that seemed to be close to correct".

Well - it's not correct at all, the colors get washed out doing that, so the "convert to linear" method (after converting the image first to 16 bits), is the way to go!

I haven't noticed this tbh. What exactly did you do? I used to do the same, but haven't done any post work in PS for a year now.

[3dWannabe]

I haven't noticed this tbh. What exactly did you do?

I believe I applied a 'levels' adjustment and changed the middle value from 1 to .454545.

That gets it close to linear, but the colors are washed out a bit in the end (compared to converting to linear) - so the method of converting it to a linear color space seems the best method.

[Tobian]

In Photoshop, it's better to use the Exposure adjustment tool, and use the Gamma value of 0.4545 - I have an action for doing just that :D The gamma value in 'Exposure' seems to look better than the levels version, for reasons I never explored, but just accepted and moved on :D

[3dWannabe]

In Photoshop, it's better to use the Exposure adjustment tool, and use the Gamma value of 0.4545 - I have an action for doing just that :D The gamma value in 'Exposure' seems to look better than the levels version, for reasons I never explored, but just accepted and moved on :D

For converting an sRGB to a linear sRGB, is there any difference between your method and the method of converting to a linear sRGB color space?

I'd hate to miss something basic when I'm setting all this up.

[Tobian]

Probably, sorry I am not an expert :)

Since most of my textures are created in sRGB space.. I apply a 0.4545 gamma to the textures (not a srgb->Linear transform) and then at render time apply a 2.2 gamma - so roughly all texture colours will be in sRGB.. but that's just my workflow and everyone works differently.

The thing is the whole 2.2/0.4545 thing is ONLY an approximation of what is going on, it's just sufficient for most applications. If you need accuracy in the colour conversions it can just get more complex! :D

One of the better way to convert a sRGB texture to Linear is to just up it's resolution to 32bpp in Photoshop, and save it out in a Linear format.. and PS did all the conversion for you :) The downside is 32bpp textures are bigger, but on the plus side, it means they will scale properly when LW does the Mip Maps

[3dWannabe]

One of the better way to convert a sRGB texture to Linear is to just up it's resolution to 32bpp in Photoshop, and save it out in a Linear format.. and PS did all the conversion for you :) The downside is 32bpp textures are bigger, but on the plus side, it means they will scale properly when LW does the Mip Maps

That sounds like a good plan, especially with 64 bit LW and 2GB VRAM!

Any advantage to one format or another? I guess you loose thumbnails with exr.

I wonder about 16 bit exr (as I understand this is a native format of 'half' for nVidia cards)?

[Zafar Iqbal]

For converting an sRGB to a linear sRGB, is there any difference between your method and the method of converting to a linear sRGB color space?

I'd say a profile conversion is more accurate than adjusting midtones since the profile also affects colors. Don't ask me for details :P but as Tobian mentioned it's not going to mean too much in the end.


I'd hate to miss something basic when I'm setting all this up.

Sure, I felt exactly the same way in the beginning, and I'm still open minded for new and better approaches - I too do like Tobian: let the textures be taken care of by the app, except that I render to linear, but that's a different story :)


Any advantage to one format or another? I guess you loose thumbnails with exr.

I wonder about 16 bit exr (as I understand this is a native format of 'half' for nVidia cards)?

I ones stumbled upon a site that explored various high dynamic formats. I tried to google it for you but wasn't able to find it. HDR was by far most dynamic but it lacked color accuracy (IIRC). EXR was overall the best. I'd recommend either EXR or TIFF as both are somewhat common compared to some of the other high dynamic formats.

EXR half float is 16 bit, but because its floating points, you'll lose data by editing in PS/AE16 bit mode because they operate with integer numbers. Use 32 bit instead. I don't have much experience with this myself, except that I do recall in my earlier LWF days, that half floats in Photoshop lead to banding sooner than expected, whereas now, when editing in 32 bit, I don't have that problem.

Regarding EXR thumbs - have a lookie here: http://matthieu.fauqueux.free.fr/dev/index.html

Edit: just found the fileformats comparison page: http://www.anyhere.com/gward/hdrenc/hdr_encodings.html

[Tobian]

Half float (16bpp) is usually more than enough for most situations, it's NOT the same as 16 bit file formats (as in Photoshop) While you will save a lot of HD space saving out in half float, unfortunatelly a lot of apps don't seem to use them properly.. i.e. PS will open them fine but won't save them out again, except as 32bpp.

In terms of colour fidelity - that doesn't make sense actually... EXR and HDR should have exactly the same 'colour' because they are floating point formats, which contain ALL colours.. the whole point about a 'colour model' is because the palette and gamut are limited. It's perhaps an issue as to how they are being displayed by your software, or if the EXR is perhaps (in PS it's likelly the case) that PS is saving with it an unsupported colourspace tag, whereas HDR supports no colour conversion information.

I'm probably missing the point though :D

[Lightwolf]

I'm probably missing the point though :D
Yup, some formats store a 8-bit colour component coupled with a 32-bit float multiplier (which multiplies R G and B).
That prevents you from storing, say, super bright yellow with a slight bit of blue (which would be a small blue value, but very high R and G).

Cheers,
Mike

[Zafar Iqbal]

Half float (16bpp) is usually more than enough for most situations, it's NOT the same as 16 bit file formats (as in Photoshop)

I hope what I wrote didn't come out this way (float being same as non float) because I meant the exact same thing as you.


In terms of colour fidelity - that doesn't make sense actually...

That was my thought as well when I first stumbled upon the page. I don't understand much of the comparison but it looks valid to me.

[Tobian]

I simply meant that if you load any 'float' format into PS (which supports float) then it works in 32bpp float mode, and you don't lose any data. If you convert it to 16 bit mode in PS then of course you are throwing away data...

and thanks Michael, I still don't understand, but I'll just agree with you, since you understand the format :D

[Lightwolf]

and thanks Michael, I still don't understand, but I'll just agree with you, since you understand the format :D
Let's see if I can make it clearer...
The 8-bit components basically store values between 0 and 1 in 256 steps, right?
If you add a single multiplier for the triplet, then you can't store RGB values such as, say 0.5, 100.0, 5.0 (R,G,B).
There is no single multiplier that can turn RGB values between 0 and 1.0 into that triplet.
The closest I can get to would be 100 with matching RGB values of 0.005, 1.0 and 0.05
However, as the RGB is stored in 8 bits only (values from 0 to 255), you end up with 1, 255, 13 (rounded, but they need to be: value * 255).
If you then read them image, you need to multiply again using the multiplier:
(1 * 100) / 255 = 0.39
(255 * 100) / 255 = 100.0
(13 * 100) / 255 = 5.07
the 255 is needed to convert the integer 8 bit representation back into a float from 0 to 1.0
As you can see our lowest component (red) is well off. And the higher the differences, the bigger the error.

One thing the author seems to have forgotten in the comparison is EXR in 32bit mode btw... just saying ;)

Cheers,
Mike

[Matt]

Let's see if I can make it clearer...
The 8-bit components basically store values between 0 and 1 in 256 steps, right?
If you add a single multiplier for the triplet, then you can't store RGB values such as, say 0.5, 100.0, 5.0 (R,G,B).
There is no single multiplier that can turn RGB values between 0 and 1.0 into that triplet.
The closest I can get to would be 100 with matching RGB values of 0.005, 1.0 and 0.05
However, as the RGB is stored in 8 bits only (values from 0 to 255), you end up with 1, 255, 13 (rounded, but they need to be: value * 255).
If you then read them image, you need to multiply again using the multiplier:
(1 * 100) / 255 = 0.39
(255 * 100) / 255 = 100.0
(13 * 100) / 255 = 5.07
the 255 is needed to convert the integer 8 bit representation back into a float from 0 to 1.0
As you can see our lowest component (red) is well off. And the higher the differences, the bigger the error.

One thing the author seems to have forgotten in the comparison is EXR in 32bit mode btw... just saying ;)

Cheers,
Mike

Come again?

:D

[Tobian]

Haha that's what I thought, but then I realised I had read his post meaning back to front. Basically what you are saying is that some HDR formats store their information in such a way as they introduce rounding errors, and therefore the colour accuracy is not as good.

I think :)

[Lightwolf]

I think :)
Yup.
Come again?
See, Tobian gets it... :hey:

Cheers,
Mike

[JeffrySG]

Just out of curiosity, why are you guys use the sRGB color space? it's a very limited color gamut as compared to AdobeRGB or some of the other professional color spaces. Why limit the color range? This is different and separate than linear or 2.2 gamma, btw.

If you're not familiar with how limiting sRGB is this link has a nice explanation.
http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm

If you're going through the work of a nice linear HDR workflow I would think it would be better not to limit your color range. If I'm missing something here, which is entirely possible, please let me know. Most of my professional experience has been with print, retouching and large format graphics so that is the perspective I usually have when I think technically. :)

[Lightwolf]

Just out of curiosity, why are you guys use the sRGB color space?
They're not. They're just assuming that the LDR footage that comes in is sRGB to start with.
And preview on sRGB because that's likely to be what the final viewing conditions are.

If you're going through the work of a nice linear HDR workflow I would think it would be better not to limit your color range.
Once you're in float you're not limiting the colour range anymore (well, you still do numerically, but not in any practical way).

Cheers,
Mike

[JeffrySG]

They're not. They're just assuming that the LDR footage that comes in is sRGB to start with.
And preview on sRGB because that's likely to be what the final viewing conditions are.

ok, that makes sense. I personally hate when we refer to LDR content as sRGB by default. It's not really accurate and kind of confusing (to me anyway) lol.

Once you're in float you're not limiting the colour range anymore (well, you still do numerically, but not in any practical way).

That's good to know. I hope that LW doesn't refer to LDR footage as sRGB when it really means something else as it will just be confusing and inaccurate - especially to all of the print people here. I brought up this point in the HC forum a while back but I don't think anyone really understood what I was referring to. Thanks for the reply, Mike. :)

[Lightwolf]

ok, that makes sense. I personally hate when we refer to LDR content as sRGB by default. It's not really accurate and kind of confusing (to me anyway) lol.
No, it isn't. But hey, humans are sloppy, that's how we're designed ;)
And in 90% of all cases whatever still you deal with outside of the print world is sRGB, or at least close.

That's good to know. I hope that LW doesn't refer to LDR footage as sRGB when it really means something else as it will just be confusing and inaccurate - especially to all of the print people here.
I don't think it refers to LDR as anything but 8-bit images.

Cheers,
Mike

[Matt]

Yup.

See, Tobian gets it... :hey:

Cheers,
Mike

He's smarter than me! :(

[Tobian]

haha AWW - I didn't understand the maths, I just 'get' that with rounding errors you get stepping or colour accuracy issues. So turn that frown upside down! :D

[3dWannabe]

Yes good example Toby, hence when you are working in LCS you need to adjust all lights and luminous surfaces with the 0.4545 gamma (or Pow of 2.2) so that makes them darker below 100% and brighter above 100%

(attached) as you can see, with a scalar value of 3 it's transformed to a value of 11.2116 - which means you'd need to set luminous surfaces which had been 300% up to 1121% - as you can see by transforming the Gamma to 2.2 (Pow 0.4545) a value of 300% would be transformed to only 164%

Sometimes you have to do it by eye though, as obviously the lighting will be totally different under LCS, but previously where my Luminous surfaces used to light interior environments used to be about 3-400% - they are now 750-900%

Are you saying that we can plug a scalar number (like 3 to represent a 300% light), and determine the correct percentage of the light using LCS which will always be a larger percentage for >= 100?

And that a 50% light would be represented by a scalar of .5, and would always be decreased?


You also need to alter the intensity of all lights with a gamma modifier, including ambient light.. Remember a 5% ambient light value, gamma adjusted = 25% !!! Even 1% = 12% - those are high values to have for ambient lights! :)


I'm a bit confused on the ambient. I did some tests where I had a Light set to 0% and ambient at 100%, and it seemed to work perfectly without any changes when I had a linear picture or a color converted to linear from 127,127,127

You seem to be saying that the ambient light would have to be turned down?

Or, is 100% a value that DOESN'T have to be modified when converting a light to linear, whether its ambient or not?

[Matt]

haha AWW - I didn't understand the maths, I just 'get' that with rounding errors you get stepping or colour accuracy issues. So turn that frown upside down! :D

I did get that bit, just winding Mike up, it's my job! :)

[COBRASoft]

I'm struggling with the latest LW HC and this linear workflow. I have my image saved in EXR format and it's supposed to be linear. When I open it in PS5 and convert it to 8 bit, it is totally screwed up. It seems like I have to do a gamma correction of 0.4545 before turning it into 8 bit. Is this correct or am I missing some things?

[Tobian]

When you convert a 32bpp image to 16 or 8bpp it usually asks you to define the gamma, where you'll normally say 2.2. Most odd!

[COBRASoft]

This is weird, when I save the result as PNG (in RGB), I get the attached result. When I open the EXR in PS it looks like the screenshot. When I convert the EXR to 8 bit, I get the second screenshot. My lighting is probably wrong, but why is my PNG looking to dark then?

I've attached my EXR too.

[Zafar Iqbal]

When you convert a 32bpp image to 16 or 8bpp it usually asks you to define the gamma, where you'll normally say 2.2. Most odd!

Hm? I never have to do that - unless my colorprofile differs from Gamma 2.2 :o

This is weird, when I save the result as PNG (in RGB), I get the attached result. When I open the EXR in PS it looks like the screenshot. When I convert the EXR to 8 bit, I get the second screenshot. My lighting is probably wrong, but why is my PNG looking to dark then?

I've attached my EXR too.

Are you sure the "HDR Toning" "Method" is set to "Exposure & Gamma", and both values are default?

Your EXR converts fine here (I'm using sRGB as my default RGB color profile in PS color management settings).

[Tobian]

My apology, by default Photoshop actually defines it as 'gamma 1.0' Not 2.2 and looks exactly the same when going from 32 bit float to 8/16 bit (save the bit depth :))

When I convert your EXR image (In PS) with the default 'exposure and gamma' setting of 0 exposure and 1 gamma, it looks exactly the same in 8/16 bit.

[COBRASoft]

Ok, I use the sRGB profile now and with exposure and gamma, I get the same result, thanks!

I have to colorcorrect that reddish/yellowish picture. I do it best before converting it to 8 bit to avoid banding to appear. Do I have to do the contrast and other post work also in 32 bit mode (if possible)? I'm wondering what results you guys would get from this simple EXR image and what I have to change in my lightsetup to get a better result? :D

[Zafar Iqbal]

Ok, I use the sRGB profile now and with exposure and gamma, I get the same result, thanks!

I have to colorcorrect that reddish/yellowish picture. I do it best before converting it to 8 bit to avoid banding to appear. Do I have to do the contrast and other post work also in 32 bit mode (if possible)? I'm wondering what results you guys would get from this simple EXR image and what I have to change in my lightsetup to get a better result? :D

Do as much as you can in highest bit depth - be aware though that color correcting in 32 bit is different than in 16 and 8 bit since you can have higher or lower than "normal" R, G and B values. Try adding +100 saturation in 32 bit and then compare with same adjustment in 16 bit and you'll see what I mean.

It's very limited what you can do in 32 bit though - I "solved" the problem by converting the 32 bit version to a Smart Object and then convert the main PS pic to 16 bit. This allows to always be able to go back to the original render and do tweaks if needed - or make copies of the SO layer and do local tweaks (I noticed problems with this workflow though but never got it solved before I discarded PS for color correcting 32bit renders).

Regarding lighting: Can't really say much about yours, except that most of the time I stop 3d work when it's almost-but-not-entirely-there. I then render out in 32 bit and take care of the rest in post. This can save me hours of work and final result won't even show didn't pull the best possiple render. That's the power of 32 bit. Play with exposure and you'll get an idea of what I mean. Make sure to compare by doing the same thing in 16/8 bit to really see the difference.

[toby]

It's very limited what you can do in 32 bit though -

Should read : "Photoshop limits how much you can do in 32bit".

32bit itself is about as unlimited as you can get, but adobe wants to trickle out any improvements to get you to upgrade as many times as possible. Nuke for example can do *everything* in 32bit, and it's been like that for over 6 years, probably before photoshop had any 32bit support at all.

[Zafar Iqbal]

Should read : "Photoshop limits how much you can do in 32bit".

You are right - I was considering it but thought I was clear enough since it was PS we were already talking about. I use Nuke too and there is simply no comparison between PS and Nuke.

[3dWannabe]

What's the proper way to use the Turbulence smoke and fire plug-in with a linear workflow?

[Matt]

What's the proper way to use the Turbulence smoke and fire plug-in with a linear workflow?

Assuming it renders to linear space, just add gamma in which ever way you prefer.

I can't imagine it would render to any particular gamma without a setting.

[probiner]

Hey Matt, hey guys.

This summer i remebered this thread when i was with my family and we decided to make a full moon stroll.
We took cameras and well... you can't see much on the pictures even with full moon. But then someone cranked up the exposure and wow... the sky is blue, the sand is yellow, there are sharp shadows and we were happy "photographers".

In college i learned that we use cone cells for color and detail and rod cells for movement and high contrast, and since rod cells are what we use at night, because they are more sensible than cones, we have black and white vision at night.
Well i never understood that, since we all think we still see colors even with dim light. But these photos blew my mind, and now i see how black and white i see things in a full moon night. If only they've shown me this in class...

Photos were taken between 1 and 2 AM, with an apperture of 3.4, 15" of exposure, ISO1600 with a compact Canon.

So what these photos could mean in this context of Linear Workflow?

(Screw Infrared :p)
Cheers

Wave cream.
http://i153.photobucket.com/albums/s202/animatics/Lightwave/th_z_IMG_5633.jpg (http://i153.photobucket.com/albums/s202/animatics/Lightwave/z_IMG_5633.jpg)

More wave cream
http://i153.photobucket.com/albums/s202/animatics/Lightwave/th_z_IMG_5639.jpg (http://i153.photobucket.com/albums/s202/animatics/Lightwave/z_IMG_5639.jpg)

More wave cream, looking like fog.
http://i153.photobucket.com/albums/s202/animatics/Lightwave/th_z_IMG_5636.jpg (http://i153.photobucket.com/albums/s202/animatics/Lightwave/z_IMG_5636.jpg)

Happy strollers ("is it over yet?")
http://i153.photobucket.com/albums/s202/animatics/Lightwave/th_z_IMG_5615.jpg (http://i153.photobucket.com/albums/s202/animatics/Lightwave/z_IMG_5615.jpg)

Sharp shadows.
http://i153.photobucket.com/albums/s202/animatics/Lightwave/th_z_IMG_5627.jpg (http://i153.photobucket.com/albums/s202/animatics/Lightwave/z_IMG_5627.jpg)

Landscape.
http://i153.photobucket.com/albums/s202/animatics/Lightwave/th_z_IMG_5628.jpg (http://i153.photobucket.com/albums/s202/animatics/Lightwave/z_IMG_5628.jpg)

[evolross]

I have to say... that's truly wicked.

[K-Dawg]

Hi guys,
I took about 1,5 hours reading thru the the thrad, watchin the videos and DL the plugins etc.

I'm still very confused.

I'll ask a few quistions, step by step what keeps me confused, and sotty if they were answered already, but my head is hurting (all I can think about is Gamma, Gamma, GAMMA) and I seem not to grasp it.

Ok lemme start.

1.
There have been several ways showed how to convert to LCS. For an example Solid Colors. I could use a step of several Nodeflows to convert the Colorpciker Color to LCS. I could install a Colorpicker that supports LCS Conversion for me and I can convert an Image to LCS by using Nodes.

Question. If I convert with Nodes only and no ColorPicker, what will be with my Lights, Background colors etc, that can't be driven with Nodes? Do I somehow have to manually compensate them to LCS?

Question 2. If I use a colorPicker that converts to LCS for me, does that also automatically convert the Lights, Background etc. colors to LCS, ad I then have not to use the Nodal conversion flow, eccept for Images?

2.
When I want to see the results Gamma Corrected, I have to apply the FP Gamma Plugin in LW. By doing that I can see the result when Render is finished.

Question. Can I export the final Gamma Corrected image with the FP Gamma plugin and Import that in PS or Fusion and use that in my workflow, or do I have to export as LCS and then Gamma in the Compositing app?

Question 2.
Do I have to export as EXR or can I export as .png/.jpg etc and still have full control of the Gamme in Compositing without any Bandind etc.?

Question 3.
What type does Fusion/PS etc have? Gamma or LCS? What type should I use for the Comp App?

3.
I would like to Multilayer and Multipass Render my Images.

Question.
Do I have to do Gamma? Can i then still have full control over Gamma in Comp and have control of the Passes and manually change them in Comp?

4.
I'd like to know what Colorspace would be best to work with. Like when I make my Textures in PS and save them. Bring them in LW and Gamma them.

Question.
What Profile would be best to use doing that? Adobe RGB or sRGB and how do I control that for monitor/TV files and what profile would be best for them?

I think that was about it.

I'm sorry, I don't want to be rude or anything. Those where just a few things keeping me confused I haven't seemed to figure that out now.

Matt, many thanks to your Tutorials, they helped to understand the need and so on, but I haven't understood the how to to it exactly.


Oh btw. I work with LW 9.6. Pleas keep that in mind with the answeres. I won't be able to get 10 for a while, so I have to stick with 9.6

Greetz

[Tobian]

not at all a complicated way of writing a question or anything!?

1a) yes you will manually have to compensate, or use either the SG colour picker, which does Gamma correction, or the Jovian one...

1b) A colour picker which can convert a picked colour, converts a picked colour :) doesn't matter where in the interface it is, so yes that will be lights, backgrounds and anything else without a node editor, which do need to be transformed too.

2) If you convert the image inside LW so you can see the gamma corrected appearance, you will need to remember that it's only appropriate for display. If you want to save it out as an EXR it should be converted back to linear.

2a) You can save it as any format, just remember the rule that: If you are saving it for direct 24/48 bit work (8 or 16 bit per channel in PS), then you should transform it to be display gamma. If it's going to be used for 96 bit (32bpp) then ideally you should have a gamma of 1 for the image. That said if it's saved in float, you can just apply a 0.4545 gamma or tell your compositing app to interpret it as display gamma, before working with it.

3) Most applications expect floating point / 32bpp images to have a gamma of 1.0. They usually apply a display gamma to them, or with more high end apps, you can create your own custom LUT - remapping the linear image into display space, to get nicer tone mapping effects.

3a) Remember with passes that it's just the same as using a full render. It's best to convert your workflow to all linear, composite them in linear, and then the compositing app will apply the display gamma so it all looks correct. Don't mix the gamma of layers, or you will get edge errors. This means you can't 'preview' what it'll look like, but then if you're just doing tests, apply a post filter for previewing inside LW (and LW10 removes the need for this!)

4) This is where it starts to get UGH. Ideally the best solution is to convert your textures from a colour space to linear. With the SG node you can specify the source CS, and with LW10 you can too. You could always just convert them in an editing app directly to EXR's - but that takes up more memory and file space...

[K-Dawg]

Thx for the respond Tobian.

1b) A colour picker which can convert a picked colour, converts a picked colour doesn't matter where in the interface it is, so yes that will be lights, backgrounds and anything else without a node editor, which do need to be transformed too.
Understand Thx. But about Background Images (or images mapped to a skydome for instance but mainly in the Backdrop). Where do I set the Color to LCS? I can't use Nodes there, wo how would that case be best? Like Matt did in the first Video, directly in the Image Editor?

The rest is clearly, thx.

2a) You can save it as any format, just remember the rule that: If you are saving it for direct 24/48 bit work (8 or 16 bit per channel in PS), then you should transform it to be display gamma. If it's going to be used for 96 bit (32bpp) then ideally you should have a gamma of 1 for the image. That said if it's saved in float, you can just apply a 0.4545 gamma or tell your compositing app to interpret it as display gamma, before working with it.
I think I understand it. Lemme recap pls.
So if I want to Export my renderings as .png or .jpg I need to Export with FP Gamma Plugin activated right? If I want to Export as HDR (I understood that EXR is a HDR) I export with an unactive FP Gamma Plugin, right? LSC has to be done, thats is clear.

3a) Remember with passes that it's just the same as using a full render. It's best to convert your workflow to all linear, composite them in linear, and then the compositing app will apply the display gamma so it all looks correct. Don't mix the gamma of layers, or you will get edge errors. This means you can't 'preview' what it'll look like, but then if you're just doing tests, apply a post filter for previewing inside LW (and LW10 removes the need for this!)
Ok, so basicly Be sure all Layers/Passes are set to same LSC otherwise the comp will be crud. Gotcha :)

4) This is where it starts to get UGH. Ideally the best solution is to convert your textures from a colour space to linear. With the SG node you can specify the source CS, and with LW10 you can too. You could always just convert them in an editing app directly to EXR's - but that takes up more memory and file space...
Understand. Thx for teh Info. So that is more a Try and Error part to fully figure out how to approach it. Will do that :)

Thx Tobian.

[Tobian]

a) In answer to your question about BG images, tricky, I just never use em, so it wasn't a problem. If it's an environmental texture, you can always use a DP texture node, and apply the gamma correction in there, but a BG, the simplest thing to do was create an HDR background, or do it in post.

b) Yes you have it correct.

c) Yep

d) no problem...

[elektronikfreak]

Great tutorial. Many thanks.

[brnac]

Thanks for share!

[Roadwarrior]

Interesting thanks for sharing with the community:thumbsup:

[tyrot]

hey matt ... can you add your additional tutorial links (2 of them in somewhere in this thread) into your first post..... ?

And also can somebody share tips for Gamma correction examples for exterior renders? For interior it is a must...for exteriors?

And Lightwolf thank you for your time for free plugins... you rock...

[Tobian]

You should also gamma correct exterior renders too, it's just that you can get away without doing it, because skylight helps to compensate for the gamma problems. Gamma correcting also helps to solve colour bleed issues, from strongly coloured walls or blue sky too.

[Julez4001]

Thank You for the tutorials.

[Laser-mark]

Thanks

[Matt]

There is a new version of this coming, first two videos are done, just working on the LW10 one now.

[Mitja]

There is a new version of this coming, first two videos are done, just working on the LW10 one now.

I was waiting for this... :thumbsup:

[daforum]

Thanks for the tutorials Matt.
I now have a better understanding of this process but there is something I don't quite understand.

In your tutorials you apply d&bw tools simple colour corrector or SG_CC Node to a SINGLE surface. Does that mean that either one of these would have to be applied to ALL surfaces?
Even if those surfaces are LightWave colours/ presets/ procedurals/ gradients added as layers to a surface channel?
For example: if the surface is just Red (nothing else) do I need to click on Edit Nodes and apply one of the above mentioned nodes?
You do open Jovian at one point and click on the Gamma out button, but i don't have Jovian.

Many thanks :)

[Matt]

Thanks for the tutorials Matt.
I now have a better understanding of this process but there is something I don't quite understand.

In your tutorials you apply d&bw tools simple colour corrector or SG_CC Node to a SINGLE surface. Does that mean that either one of these would have to be applied to ALL surfaces?
Even if those surfaces are LightWave colours/ presets/ procedurals/ gradients added as layers to a surface channel?
You do open Jovian at one point and click on the Gamma out button, but i don't have Jovian.

Many thanks :)

Yes, you'd need to apply it to all areas using colour, which is one of the reasons why doing this in LightWave 10 is MUCH easier.

Without Jovian, removing colour space information prior to v10 from colours was not easy, again this is something much easier in v10.

[Matt]

In tell ya, doing these videos is not fraught with annoyances ...

I need a sound proof room!

:D

[4dartist]

Haha, nice.

[Mitja]

What did you say about his mum?! Haaaaa

[Matt]

What did you say about his mum?! Haaaaa

Serves him right! He clearly does not know the importance of Linear Workflow! :D

[JeffrySG]

In tell ya, doing these videos is not fraught with annoyances ...

I need a sound proof room!

:D

LOL, tell me about it!

I'm sure the new videos will be great, Matt! Looking forward to watching them. :)

[daforum]

Yes, you'd need to apply it to all areas using colour, which is one of the reasons why doing this in LightWave 10 is MUCH easier.

Without Jovian, removing colour space information prior to v10 from colours was not easy, again this is something much easier in v10.

Thanks Matt :)

With a lot of surfaces to de-gamma that would take a very long time. Is there a collective way to do all surfaces at once (for LW9.6?)

[Matt]

Thanks Matt :)

With a lot of surfaces to de-gamma that would take a very long time. Is there a collective way to do all surfaces at once (for LW9.6?)

Not as far as I know, hence why v10 addressed this.

[Tobian]

It's not as simple as it first appeared Matt. The node editor doesn't get gamma corrected (though any textures you have used will). Though Michael Wolf's new colour correction node (which works with LW10) will do that for you, albeit one surface at a time, as always.

[funk]

I sent in a bug report for no color correction in the node editor (case 35845) and hypervoxels (case 36516). I'm sure there are other places too.

Seems like color correction is only 50% complete in lw10

[daforum]

Matt. I really like your tutorials and have tried out what you recommend and I have been converted to using this technique as the difference is incredible (although I am worried about embarking on a scene with lots of objects in it!)

Here a couple of examples.
The first, on the left has no gamma correction. The second on the right has de-gamma applied to the brick image and the floor (giving it a lovely soft shadow) and gamma of 2.2 applied. :thumbsup:

[Matt]

It's not as simple as it first appeared Matt. The node editor doesn't get gamma corrected (though any textures you have used will). Though Michael Wolf's new colour correction node (which works with LW10) will do that for you, albeit one surface at a time, as always.

Jamie is gonna be looking at this, and hopefully some of the other requests made by users.

[Matt]

Matt. I really like your tutorials and have tried out what you recommend and I have been converted to using this technique as the difference is incredible (although I am worried about embarking on a scene with lots of objects in it!)

Here a couple of examples.
The first, on the left has no gamma correction. The second on the right has de-gamma applied to the brick image and the floor (giving it a lovely soft shadow) and gamma of 2.2 applied. :thumbsup:

Thanks, yes, it's definately the way to go when doing 3D, it's why everyone is talking about it!

[Tobian]

Superb Matt. I can make do with Michael Wolf's excellent colour space node till then! :)

[Lightwolf]

Superb Matt. I can make do with Michael Wolf's excellent colour space node till then! :)
Which has just been made public as a part of the free db&w Tools V1.8 :D

Cheers,
Mike

[Matt]

You're a star Mike!

[Redfisher]

Is the color picker in LW10 sRGB or linear color space? Last night I changed all of the inputs to sRGB and outputs to sRGB and everything just gets washed out. I followed along with Jared's video, BTW.

Thanks!!

[Matt]

If you set the picked colour inputs to sRGB and display space to sRGB that shouldn't wash out the colours, that's the correct setup.

BTW: The new videos on this subject are done. We'll be uploading them very soon.

[Redfisher]

Thanks Matt!! Once you adjust the lighting and re-pick the colors after setting the input/output to sRGB, all looks good.

[Oedo 808]

BTW: The new videos on this subject are done. We'll be uploading them very soon.

Will previous videos be required reading* along with the new ones? I've been meaning to pay more attention to this subject, but I'm too much of a bum. If the new vids are sufficient, I'll just wait for those.

Cheers.

[Matt]

Will previous videos be required reading* along with the new ones? I've been meaning to pay more attention to this subject, but I'm too much of a bum. If the new vids are sufficient, I'll just wait for those.

Cheers.

No, these will replace them, as it goes over the same information, but hopefully better this time!

[COBRASoft]

I'm very curious Matt, now give that new version :).

[Oedo 808]

No, these will replace them, as it goes over the same information, but hopefully better this time!

Groovy, look forward to them.

[jay3d]

I have noticed that color pickers inside nodes are not affected by Picked Colors color space option, it needs to be manually corrected thanks to Mike's dbw tools color space node. But this needs to be fixed nonetheless.