gamma correct each color slot?

[Jozvex]

Essentially yes. Very boring I know!

:hmm:

[cpan]

aye, as Joz precisely said! basicaly all colors you set using the color picker aren't what you think they are.. the monitor "has" a gamma of its own:) at our studio i've setup a script to fix this on the fly, but i'm afraid i can't post it here.

good luck and a great new year to all of you!
calin

[royterr]

thanks for the info guys Jozvex.
cpan, could you just tell me what your script does?

[Hamburger]

I still think this workflow could be easily resolved if Maya could manage this type of stuff better and I really hope something gets improved, because it does become hard - especially with big scenes and trying to visualize it through the viewport which becomes darker due to the gamma correction!

I'm dreaming, thinking out loud and way off-topic here, but wouldn't it be best for us all lighters/renderers if the Render View was at least capable of adjusting the gamma after render or during the render somehow?

Would I be right if I said the redundant workflow of gamma correction nodes wouldn't be needed anymore if the gamma correction was done in Render View? Light would bounce of textures more naturally, bump map gamma correction node confusion would be eliminated etc...at least in my mind...wish I had the coding background...

Anyway...

royterr...I'm assuming cpan's script attaches a gamma correct node to the colour swatch with correct settings. There are some other scripts on the net that can do this already but I couldn't find them again sorry. Try djx's blog, 3delight blog etc...I think it was on one of these sites.

[MSB]

I know of 2 ways of linearize stuff.

from jdx's blog.

1) set mr render buffer's gamma = .454
2) set data type to 16bit (half).
3) attach mi_simple_exposure to MR_Camera_Lens, and set its gamma to 1.
4) render in batch render to get an openEXR file that is linearized.

However, When I try to render images using the old method that I know of, I get different results ( relatively brighter).

1) fileTexture -> gammaCorrect (gammaX,Y,Z = .454) -> LambertMeterial ( for this e.g.)
2) set mr render buffer's gamme = 1
Rendered in openEXR 16-bit (half).

When I open the EXP files in PS, they look different. However, When I convert them to 8bit images (without any color modification) , both images give me the same result.

Any idea why ?

[mr Bob]

The best method is to keep everything in Maya with a gamma value of 1 .That means you keep a linear workflow. All you need to do then is fix up your gamma corrected texture maps. Then in post you can set the gamma !!!

B

[royterr]

1) set mr render buffer's gamma = .454
2) set data type to 16bit (half).
3) attach mi_simple_exposure to MR_Camera_Lens, and set its gamma to 1.
4) render in batch render to get an openEXR file that is linearized.


1) fileTexture -> gammaCorrect (gammaX,Y,Z = .454) -> LambertMeterial ( for this e.g.)
2) set mr render buffer's gamme = 1
Rendered in openEXR 16-bit (half).

here's the PSD (http://sor.typepad.com/files/2-gamma-workflow-comparison.psd)

as you said, those methods gives different results:
the first one is always slightly brighter than the second, i would really like to know why.

[MSB]

K, I have been reading quite extensively about gamma correction topic. I read many of the articles in this link -> Here (http://forums.cgsociety.org/showthread.php?t=610790) <- so far.

Both methods are essentially the same, however, this one

1) set mr render buffer's gamma = .454
2) set data type to 16bit (half).
3) attach mi_simple_exposure to MR_Camera_Lens, and set its gamma to 1.
4) render in batch render to get an openEXR file that is linearized.

is a lot faster. For you don't have to add a gamma correction node after each (color driving) file texture. However, the drawback is that height based maps (disp/bump/normal maps) need to be gammaed ( gamma = 2.2) to be get the desired levels. ( .454 * 2.2 = 1)

Now, from my understanding from all the articles that I read, they BOTH should give the exact same result. Both methods are trying to offset the gamma curve.
So, why is it happening ? I think maybe because when you set the framebuffer's gamma = .454 , you are NOT adjusting the light's colors too. Making them NON linear aswell. I tried a simple test. (HDRI = .5 gray , i.e. no image mapped, only a constant color).
I am not sure whether MR takes the color information from nodes as being (linear) or non linear.

What: I am checking if the framebuffer effects the lights' colors.

Why: To see why each of those methods are giving different results in PS.
I am using a Spot light which has its color attribute mapped with a ramp procedural texture.

here's my test
http://img187.imageshack.us/img187/605/testmx1.jpg

Note that I did render them to 16bit (half) openEXR and while gamming them with 2.2 , it didn't give the same results. I am assuming that the simple exposure shader doesn't put the final output under some ICC color profile.
Moreover, those results that are mentioned in this image, are directly from the render view. Additionally, seting the gamma = 2.2 manually in PS (Via exposure layer to the openEXR files) doesn't give the same results.

Result: darker image when you don't use djx's method.

So, any ideas why those 2 methods are not giving the same results ?

PS: I believe that adding a mi_simple_expsure is pretty useless if you are planning to take it to an external tone mapper in djx's method.

[djx]

Its kind of flattering to see my name mentioned on the same page as the expert floze, but I must make a comment to try an clarify/correct what MSB is writing.

MSB is making some reference to what I wrote about linear workflow on my blog. I discussed my experiences and conclusions and also refered to other approaches, like the way floze explains it in his tutorials. And I followed my first post with a correction where I changed my methods based on some new insights, and this brought it more into line with the way floze is doing it.

But I fear I may have made it confusing for people - even though that was the opposite of my intention. Hey I even confuse myself :argh:

Anyway MSB, in your picture with "djx" you wrote frame-buffer gamma=.454 and lens gamma=2.2, but I would NOT do it like that. I would use one or the other, NOT both together.

But that is why it is confusing. I prefer to use frameBuffer gamma=0.454 and lens gamma=1, except I have found it causes problems with eliptical filtering and openEXR fileTextures. These are wierd artifacts that only show up using finalgather. The last project I switched back to using fb-gamma=1 and lens-gamma=2.2 to get rid of those artifacts.

And things change if you render to half-16, and so on and so on.
And photoshop and aftereffects also have color management settings that will display things differently depending on the format and embedded profile, and they will save differently too. Its a bit of a mess - but one we learn to live with. :scream:

I think you are doing the right thing in studying how all this works, and it is great that you post your findings here. There are so many factors, that I think each person needs to figure out how to make it work in their pipeline.

-- David

[Jagdpanther]

Looking at all this stuff am I correct that gamma correction is something that only has to be done when using Mental Ray's sun / sky features?

thanks

[djx]

No, that is just one case where the shaders were created with physical correctness and therefore gamma in mind. Unfortunately the implementation of a linear workflow and gamma in maya is not as straightforward as you would think and there has been much discussion about how it can be done. Have a read here for one good explanation (http://3dlight.blogspot.com/2008/09/linear-workflow-for-maya-mental-ray.html).

-- David

[royterr]

I prefer to use frameBuffer gamma=0.454 and lens gamma=1, except I have found it causes problems with eliptical filtering and openEXR fileTextures. These are wierd artifacts that only show up using finalgather. The last project I switched back to using fb-gamma=1 and lens-gamma=2.2 to get rid of those artifacts.

i am glad you shared that, cause i was intending to use that method on my next project.
so for me it's back to square 1 : gamma correct each slot and avoid artifacts.

[MSB]

god, whenever I think that I'm done with readings, I realize that there's much more :cry:

Okay, I spent the last 12 hours reading about gamma and re- reading the this (http://forums.cgsociety.org/showthread.php?f=2&t=610790&page=13&pp=15)thread.( wasted 2 hours on earthy stuff :blush: )

Anyway MSB, in your picture with "djx" you wrote frame-buffer gamma=.454 and lens gamma=2.2, but I would NOT do it like that. I would use one or the other, NOT both together.

But that is why it is confusing. I prefer to use frameBuffer gamma=0.454 and lens gamma=1, except I have found it causes problems with eliptical filtering and openEXR fileTextures. These are wierd artifacts that only show up using finalgather. The last project I switched back to using fb-gamma=1 and lens-gamma=2.2 to get rid of those artifacts.


Changing Frame buffer's gamma seems to generate a wide range of problems for many people. Emil3D mentioned it somewhere in the thread. Therefore, it should be avoided. Nonetheless, I will try to do extra testing on this claim, that framebuffer's gamma do some " compensation for your shaders behind the scenes." ( Emil3d, the same thread again). I hate adding a freaking gammaCorrect node after each single filetexture or procedural.



And things change if you render to half-16, and so on and so on.
And photoshop and aftereffects also have color management settings that will display things differently depending on the format and embedded profile, and they will save differently too. Its a bit of a mess - but one we learn to live with. :scream:

Hmm, for photoshop, it's by default set to CMKY. I mean by this , view -> color proof -> cmky. This -> should <- be changed because it applies a gamma on your linear image and when you add an exposure layer on top of your layer, you are basically gamming it twice. (again, Emil3D said this and I found it to be true !)

here's an interesting quote.


When rendering to Float 32 bit file format that will be tone mapped outside Maya (that is without using mia_exposure_simple or photographic), the framebuffer can be used as an alternative to using gamma nodes to ungamma 8 and 16 bit textures. However it calculations on the input are not exactly the same as gamma node calculation on textures even though both actions have the same goal. Because of that the result is also slightly different and it is hard to say which one is better. Correcting textures with frambuffer gamma is less hassle but it also doesn’t gamma correct the color swatches which still need to be taken care of.

Regarding your Photoshop settings, they are fine but it is more important what is selected in View > Proof Setup menu. By default it is Working CMYK which on 32 bit images will apply gamma of 2.2 on top of your rendered image making it twice as bright. So to avoid that change this to Monitor RGB.

Now, from here (http://3dlight.blogspot.com/2008/09/linear-workflow-addition-1.html)

Now the texture is correct, however the procedurally mapped sphere has not changed. the mid-grey parts of the checker are not appearing close to 128,128,128. So we do have a problem here. Framebuffer gamma is not adjusting our color swatches, so we must do it manually.

http://4.bp.blogspot.com/_oaAarvTLAq0/SNfanI_K8RI/AAAAAAAAAHc/3p0dJ9sx0fY/s400/gammaNodeGraph.jpg

Above, we see the graph and attribs of the gamma node. Now the procedural is corrected for linear workflow, and the desired final result is this:


What I don't understand is that why is Andrew adding a gammaCorrect node, if we are changing the frame buffer's gamma = .454. Why is he passing the procedural texture via a gammaCorrect node (while not the same for a fileTexture) ? I did a test and found that the frame buffer does indeed de-gamma the procedural textures just as file textures ( I baked a checker map into a file texture). In this example, it looked like that he de-gammed the checker map twice. The first time by the frame buffer, and the second by the gammaCorrect node (gamma = .454). Thus, from my understanding, it is totally wrong.

I've seen this repeated many times, so I should repeat it here. In case some wondering soul comes here and starts asking questions !

Honestly, all the linear discussions I have read talk about " simple " situaitons. Nothing in depth regarding multi passes/layer composing and individual maps and AO/RO generation or motion blur/samples. However, I have read in that thread that linear workflow do indeed reduces flickering ( because things are mathmatically accurate when processed via the renderer). I did manage to rebuild my scene ( to some extent) using a linear workflow, I am getting more intersting results, but I found some intersting things today, hope it helps someone else !

1) -> ANY <- map that is generated in PS or taken from textures should be degammed. Yes, and I do mean bump/normal/disp/spec (alpha)/reflection (alpha) you name it. Why ?
Because those images are being painted and modifed in 2.2 gamma space , thus , they should be moved to linear space again. However, this doesn't do any serious change regarding Bump maps/ normal + disp ( not 100% sure, but I believe the same situation) when they are going to change the normals of the surface. However, if they were produced via the computer itself, such from applications as Zbrush/mudbox w\e they should NOT be deggamed. For they are already in linear space because they are generated by pc and no gamma was applied.(Source, that thread, do read it and every article there !)

2) Do NOT degamme in PS , do it in the render time for it gives better results when it's being sampled at sample level rather than pixel level ( the gamma correctionFunction will be called each time it's being sampled ?)

3) Lights' colors need to be driven via a gamma correct node, why ? I didn't quite understand it, gonna ask the gurus there :beer:

Here's an interesting quote from gerando
Linearizations must be performed for all components that affect colors in final render: plain colors, textures, lights, environment maps.

4) White or black values in your lights/ meterials/shaders should not be driven via a gamma. From my understanding

L = V ^ gamma. 1^ ( gamma) = 1 , 0^(gamma) = 0

So, they could be left as is.

This is what I did understand so far. There are more subtle things that are interesting, but best being read by you if you are interested !

Since I use the search function " quite " alot, I believe to make it easier for you. I am asking " complement " information here (http://forums.cgsociety.org/showthread.php?f=2&t=610790&page=13&pp=15)in page 13 or 14.

Man, if you locate any mistakes/improvements w\e that you want to add , please do so !

I will try rebuilding my scene again from scratch fallowing the steps from 1-4. If i find something intersting, i will surely post it here. Hope it helps someone.

[royterr]

MSB, thanks alot for the info.

4) White or black values in your lights/ meterials/shaders should not be driven via a gamma. From my understanding

L = V ^ gamma. 1^ ( gamma) = 1 , 0^(gamma) = 0

So, they could be left as is.

if you have for exemple a mia_material, you dont use a gamma correct node for the black/white slot of the reflection value.
you only use a gamma correct node if you are applying a black/white texture to this reflection slot right?

[MSB]

I didn't quite understand your question. But I think you meant that if you are passing black ( RGB = 0 for each channel) they should not be corrected because " mathematically" they wont be affected by whatever exponent. However, If you have a fileTexture which has not a 0 or 1 color information, then it should be passed via a gamma correct node= .454, so that you offset ( cancel the gamma = 2.2 effect ) the response ( gamma) curve.

[royterr]

I didn't quite understand your question. But I think you meant that if you are passing black ( RGB = 0 for each channel) they should not be corrected because " mathematically" they wont be affected by whatever exponent. However, If you have a fileTexture which has not a 0 or 1 color information, then it should be passed via a gamma correct node= .454, so that you offset ( cancel the gamma = 2.2 effect ) the response ( gamma) curve.

i meant simply that if assigned a 40 percent gray to my reflection color slot (no texture), do i need to gamma correct it?

[MSB]

i meant simply that if assigned a 40 percent gray to my reflection color slot (no texture), do i need to gamma correct it?

Yep, you should.

[Ash-Man]

I apologize if this was already mentioned, but her is a MEL that will do the Job

http://toi.bk.tudelft.nl/?module=meldb&page=details&sID=42 (http://toi.bk.tudelft.nl/?module=meldb&page=details&sID=42)

[Wolfganng]

I have been doing a ton of tests during the past 6 months regarding the gamma/color swatches thing when using exposure controls. It is obvious by now that the gamma correction has to be done to textures and color swatches in materials. But there are a ton of different color swatches in many sections, and Ive always wondered up to what point you have to go. And it has risen some questions:

1- Do color swatches of lights have to be gamma corrected?
I think yes, they have to be. Lights looked so dead and desaturated without it, that regardless of whether it has to or not, i use it most of the time. But this raises another question

2- If a light has a CIE_D or blackbody node connected to thhe lights color, does the node have to be gamma corrected?
This one im not sure, if the first question is a yes, I assume this one is a yes also, since I believe the blackbody and cie_d nodes return color information, but im not sure if internally the renderer treats them as something different.

3-What about photon color?
This one has rattled my brain for a while. The photon color must match the light color, but I havent found a way to connect a gamma correct node to the photon color. I once tried something that connected theem, but for some reason the photon color kept resetting to white.

4-What about the whitepoint in the exposure_photographic node?
Ive tried it, by connecting mib_blackbody ---->gamma correct ---->exposure whitepoint, and it creates an interesting look sometimes. Yet Im a bit bafffled at which way is the physically corrrect one.

5-What about ground color and night color in the physical_sky node?
No idea on this one either. In some night renders Ive done, to get a slighty purplish night sky Ive had to plug a gamma correct in the night color slot, otherwise the colors seem washed out.


Im interested in seeing if someeone has some answers for this. Since im not sure about the answers to some of these, Ive sometimes done them in some renders and sometimes not, depending on the situation and lighting conditions, but im interested in standarizing the process to try and script it or something, because it takes such a frigggin long timee to plug gamma correct slots in colorr swatches, more so when you have dozens of lights on a scene (unfortunately putting gamma=0.455 in the framebuffer does not change swatches, only textures). Im gonna try and make some test images to illustrate the differences im talking about. Specially which is the correct workflow for the color of the lights and the photon color, and wether or not to gamma correct cid and blackbody nodes.

Also, check these tools also:
http://3dlight.blogspot.com/2008/09/gamma-tools-10.html
A great set of tools, which ive used for a while.

[Mauritius]

I know of 2 ways of linearize stuff.
1) set mr render buffer's gamma = .454
This will completely not work! This is not lienarizing the image at all.

You need to have gamma-corrected values for the light surface interaction during the render. You can not remove an error that was "burned" into an image that used sRGB or gamma 2.2 textures/colors on surfaces by applying a 1/2.2 gamma to that image after it has been rendered!

[...]
However, When I try to render images using the old method that I know of, I get different results ( relatively brighter).
[...]
Any idea why ?
The short version is: if this is not obvious to you, have not understand color/gamma in CG at all. :)

There is a shitload of information on the web and in the literature about this. But in any case: the first method (applying a 1/2.2 gamma to the final image) is plain wrong.


Beers,

Moritz

[MSB]

This will completely not work! This is not lienarizing the image at all.

You need to have gamma-corrected values for the light surface interaction during the render. You can not remove an error that was "burned" into an image that used sRGB or gamma 2.2 textures/colors on surfaces by applying a 1/2.2 gamma to that image after it has been rendered!


Hmm, the MR render buffer will be " activated " after the sampling ? However, according to MR manual this option (render buffer -> gamma) should degamma each single file texture before teh renderering ! ( if i remember correctly !)

Anyways, I don't use this method ! It keeps on introducing artifacts. In fact, I rather use gamma correct nodes for any light/file texture/meterial/shader that has a non black or white input. ( L = V ^ gamma, 1 or 0 won't be affected by any exponent).


The short version is: if this is not obvious to you, have not understand color/gamma in CG at all. :)

There is a shitload of information on the web and in the literature about this. But in any case: the first method (applying a 1/2.2 gamma to the final image) is plain wrong.

Gamma correct node should be connected to color slots in lights [according to gerarando]. Because, the color should be linearized [ maya views colors after they have been modified by the sRGB curve], so that MR will get the mathmatically accurate numbers, right ?

But i never applied a 1/2.2 gamma to the final image ! it's wrong ! :blush:
I did post something in this thread , right after posting this question. Can you check it, please ? I mean my workflow for gamma correcting. For I think there's something still wrong, however I am not able to locate it.

To summerize my workflow for you:
1) Any input that the meterial has will be driven by a gamma correct node , unless it's black or white. ( Computer generated images are Linear by default, so no need for gamma correction here)
2) Lighs: their colors will be driven by a gamma correct node , unless the colors are white or black. Then, there is no need.
3) For viewing while renderering, use a lens that applys a gamma = 2.2
4) delete the lens before the final render and render in HDR.

However, I do believe that there's something wrong, I dont seem to find it.

@Wolfganng: scary questions !

3-What about photon color?
maybe if you take the (gamma) root for both sides of equations and set it for the Value of the photons' colors ?
L = V ^ gamma ( you input V)
so if we want V = L
I believe if you just raise the V input (value) to 1/2.2 it should do it.


EDIT: This is wrong. The monitor fallows a curve of 1/2.2. Moreover, since each color's swatch in maya fallows a sRGB curve of 2.2 gamma. Those colors should be raised to 2.2 gamma to compensate for the monitor's curve of 1/2.2.

Sorry for that !



THANK YOU !

[Undseth]

Is poor anti aliasing an issue when doing tonemapping outside Maya, of a image rendered out as a high dynamic range image?

[Mauritius]

To summerize my workflow for you:
1) Any input that the meterial has will be driven by a gamma correct node , unless it's black or white. ( Computer generated images are Linear by default, so no need for gamma correction here)
2) Lighs: their colors will be driven by a gamma correct node , unless the colors are white or black. Then, there is no need.
3) For viewing while renderering, use a lens that applys a gamma = 2.2
4) delete the lens before the final render and render in HDR.

That is the right way! :)
Of course, this is only the most basic approach. To really have good control over the result, you need to be able to simulate the final display device on your screen through something like e.g. Cinespace or a viewer that supports 3D LUTs.

As far as 2. goes: I on't consider light colors crucial to undergo gamma correction because one usually tweaks light colors by looking at the final image, fed through a target device LUT (in your case, the 2.2 gamma you apply to the image during test rendering).

.mm

[Mauritius]

Is poor anti aliasing an issue when doing tonemapping outside Maya, of a image rendered out as a high dynamic range image?
Ideally, tone mapping operators are ran on pixel samples, not final pixels.
If this is possible depends on the renderer in question.

.mm

[Undseth]

Sounds like bullshit to me, what does that even mean?

How is it possible at all, to do tonemapping on a sample level outside Maya?

[Mauritius]

Sounds like bullshit to me, what does that even mean?
How is it possible at all, to do tonemapping on a sample level outside Maya?
If you re-read my reply carefully, you'd surely notice that I never mentioned rendering with the Maya "renderer".

If you don't know what pixel samples are, I'd suggest you brush up your knowledge on how renderers construct the images they create.
If you do know, your are welcome to join our debate on this topic at the 3Delight forum (http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=1210). Note though, that it is undisputed, even there, that tone mapping works best on pixel samples. The subject of debate in the above thread is solely if they would work good enough, still, if ran on shading samples. :)

.mm

P.S.: for me "what does it even mean" translates to "I don't understand". How something one doesn't understand one can afford having an opinion about (assuming one wanted to count "bullshit" as such), eludes me. ;)

[Undseth]

I guess this is about optimally tonemapping pixel subsamples and not "pixel samples" am I right?

If you re-read my reply carefully, you'd surely notice that I never mentioned rendering with the Maya "renderer".

Well, this part of the cg talk forum is about the Autodesk Maya application and I did ask specifically about tonemapping outside Maya, as in; rendering with mental ray for maya.

A suitable response would be "I honestly do not know an answer to your question in regard to stuff rendered out with maya/mrfm". And since you show no specific knowledge beyond hinting at tonemapping with pixel subsamples, I hope you understand I am unfulfilled by your reply.

I walked through teargas the other day and have no qualms about telling you to go **** yourself. :D

To finish off, I assume then that there are no known software that tonemap stuff on a pixel subsampling level.

I do want to take a look at the 3delight forums. I do enjoy reading about the mysteries of linear workflow and such.

Edit: Nice thread on 3delight, I think I'll go read a book. This one named "Organs without bodies" by Žižek seem abit easier to follow.

Edit2: Yes, I am sneaking in another edit here. I did read through the whole thread more or less but it was obvious that it was more complicated than it was interesting. I plead general ignorance as well, I just wanted to pose a question that I thought was relevant and hoped that some guru might elaborate around the issue, like they tend to do on cgtalk.

[Mauritius]

I guess this is about optimally tonemapping pixel subsamples and not "pixel samples" am I right?
I have no idea what pixel subsamples are. The term used throughout the industry, particulary in the literature, is "pixel samples". These are the discrete samples that get combined to approximate the value of the image function over the pixel in question.

Regarding your flamebait: there are many renderers integrated with Maya. I can't find any rule that limits discussions in this forum to solely those that Maya ships with.
But even as far as these go: mental delay does allow access to pixel samples.

And as far as other renderers that people, believe it or not, do use with Maya: Pixar's PRMan does. DNA's 3Delight does. Sitexgraphics' AIR does. In fact, any RenderMan compliant renderer that implements the standard display API from Pixar does. It just requires writing some code yourself in all cases, to do it (comfortably).

In PRMan it is even possible to do it w/o writing any code. The exact method is detailed in the thread in the 3Delight forum, that you found too tedious to digest.
So tone mapping pixel samples while rendering from Maya is possible, right now, to e.g. users of RMan for Maya Studio. Which, I believe, is a plugin to bridge PRMan with Maya for the purpose of rendering.
I might certainly miss something, but I think the terms "Maya" and "rendering" make this a fitting enough topic for this forum and if we add "tone mapping", even for the very thread here. ;)

Of course, your are absolutey welcome to ignore all this and just keep tone mapping actual pixels. And thus be forced to live with the limitations that are inherent to this very method.


Beers,

Moritz

[royterr]

Here's what Bart from the Lamrug forum has to say on the subject:


I understand that there is a proliferation of this type of work flow. But personally, I would not recommend this type of work flow. It is too complex and is bound to create mistakes where they normally would not occur.

I would use linear light values everywhere, pre-color correct any images you might use off the net, and only look at the results in a tone mapping image display appropriate for your environment.

Use the same tone-mapping display application to look at both input and output images, or even solid colors if you must. So, all render input and output values are in the same space.

Think of the diffuse and specular/reflection colors as coefficients, or multipliers, reflectance functions.

Specifically, your question is hard to answer without knowing what the RGB color is used for.

Finally, do not use tone-mapped render results as input to compositing. Again, my preferred workflow makes this very simple to manage and control.

[Mauritius]

Here's what Bart from the Lamrug forum has to say on the subject: [...]
I don't think anyone here suggested tone-mapping anything that was to be altered afterwards (whether that be using it as a texture or as an input in a compositing app).

But there is the issue of aliasing of bright highlights in float images.
This can only be resolved if the image is available as samples and is tone mapped before the samples are being filtered into the resp. final pixel's color.
Modifying sample-based images is not feasible with current hardware. It might be possible for a still image which uses <10 samples/pixel, so you'd "only" have to deal with 10 times the data per frame in compositing before you can tone-map.

But for most stuff rendered in production, 20x20 pixel samples isn't uncommon. We're talking a 40k wide image here. Not many compositing apps can deal with files like these for starters and even then you might run into other obstacles, e.g. RAM/swap, even on a 64bit system with 32GB of RAM.

You are then down to three alternatives:


Tone-map inside the renderer and accept the fact that your are comping non-linear data afterwards. This might be acceptable if you are working towards a stylized result anyway (e.g. in advertising etc.).
Tone-map and comp inside the renderer. If your compositing ops are simple enough or you can expose the engine of the compositing application to the renderer, running a compositing script on individual pixel samples inside the renderer becomes possible.
Command-line comp apps like Shake & Nuke particularly make this a possibility. I.e.: build your comp tree with a 2k res linear image interactively, then apply it by re-rendering the source image at 2k with the required number of samples and apply the script inside the renderer, through a shader that calls the comp app for each (or each cluster of) sample(s).
Tone-map outside the renderer and the comp app, but after comping. This requires writing the image out as samples (the 40kx30k file I mentioned above) and feeding that to a command line version of the comp app running the script that was prepped before with a 2k frame. This is similar to working with proxies. And the comp app better be able to process the image in tiles ... ;)
When done, downsample to the target res (2k) as a final step in the comp script, delete the intermediate sample files.
I haven't heard of anyone who's done this yet. The reason is probably that the typical HDR tone-mapping look has not been used in any movie (I'm aware of).
And that most senior compers are quite good at doing "manual" HDR compression, if necessary.

Anyway, this is really a different topic (tone-mapping final images vs gamma correcting inputs).


Beers,

Moritz

[royterr]

Also, note that this only applies to colour space, ie diffuse and reflection textures. Don't do something silly and apply gamma nodes to bump and spec textures, as they're really controlling data, not colou

found this here:

http://www.tokeru.com/t/bin/view/Maya/MayaMentalRay?rev=24#Tutorials_Tips_n_Tricks (http://www.tokeru.com/t/bin/view/Maya/MayaMentalRay?rev=24#Tutorials_Tips_n_Tricks)

[royterr]

Ok so finally, these are the values that must be gamma corrected in a typical mia_material:
diffuse color
reflec color
refrac color
color max distance
translucensy color


these should not be gamma corrected:
bump map
displacement

the mysterty still remains for these values (assuming you are applying a black and white image file to these slots, should you gamma correct them, yes or no?):

Diffuse weight
Diffuse roughness
reflectivity
glosiness
transparency
glosiness
translucensy weight
ambient shadow color
ambient light color
specular balance
cutout opacity
additional color

[Ironhalo]

you only need to correct inputs that will use a non black/white rgb value. that includes greyscale. if you check the connection editor and the attr in question has an rgb input, it may need correction. things like diffuse weight and reflectivity are only 0 to 1 values meaning they only accept a singular value. they should not be corrected.

[Mauritius]

you only need to correct inputs that will use a non black/white rgb value. that includes greyscale. if you check the connection editor and the attr in question has an rgb input, it may need correction. things like diffuse weight and reflectivity are only 0 to 1 values meaning they only accept a singular value. they should not be corrected.
No.

Diffuse weight is just a stupid multiplier for the duffuse color (map). Mostly for people that need to defer this mult to render time (instead of just multing the textures together b4hand, e.g. in Photoshop).
As such, any non-linearity in this slot directly affects diffuse color as well. So this needs to be corrected for diffuse weight. Aka: this texture should be linearized as well, even though it is just a "grayscale".

For reflectivity it depends. Because the effect is really hard to tell w/o rendering a final image anyway. But if you go by guessing e.g. a 50% reflection intensity by just looking in your paint app, the you can expect to get results closer to what you want by linearizing this as well.

.mm

[MSB]

I found out that linearizing specular driving channel ( grayscale/scalar) gives much more of an expected specularity. On the other hand , i didn't try that yet on bump maps. But I will be painting everything in a linear fashion in PS, and save my self the hussle of de-gamming everything later on and possibly doing mistakes.