[big K]

hello,

as i render much of my work with vray and use linear workflow (apply a 0,454 gamma to all textures), i wanted to ask if this is necessary for maxwell, or does it compensate this automatically?
is there anything else to consider for textures in maxwell?

cheers
michael

[tom]

You mean 1/2.2? Well, the textures are in 2.2 of course and Maxwell output gamma is 2.2 inverse so, it auto-compensates. If you're going to use 1.0 gamma expecting the textures look the same you should pre-modify the gamma of textures as you say. It's nothing special to Maxwell.

[big K]

o.k. thank you Tom, i just wanted to be sure.

[tom]

Recently, I see similar questions about gamma and linear workflow. Could you present an example showing your workflow? Why do you modify textures? What output gamma do you use and how does it end up?

[zdeno]

here you are Tom : there is really good explanation
http://www.aversis.be/tutorials/vray/es ... mma_01.htm

[big K]

hi Tom,

yes sorry, didn´t see your further interest. thanks zdeneo.

here is another good link.
http://www.gijsdezwart.nl/tutorials.php

[tom]

Since from the beginning, Maxwell also does this on its output already. Making the internal calculations in linear gamma and outputting a gamma corrected (2.2 by default) image. So, you shouldn't worry about the problem illustrated in the links. Makes sense?

[big K]

well, as the results of maxwell look very convincing, i am sure everything is allright.

it is only if you look at my link, that vray also works in linear gamma. but the input of the textures is in gamma 2.2. this is where the correction of the input textures comes into play. so you say that maxwell transfer these automatically into linear gamma?

[tom]

so you say that maxwell transfer these automatically into linear gamma?

Exactly. Maxwell applies 2.2 inverse gamma to user input (textures and colors in reflectance and transmittance) for bringing them into linear space first.

[dmeyer]

so you say that maxwell transfer these automatically into linear gamma?

Exactly. Maxwell applies 2.2 inverse gamma to user input (textures and colors in reflectance and transmittance) for bringing them into linear space first.

Tom, Is this true for all textures? Even ones already in linear space?

[tom]

Input conversion is only for color textures (reflectance, transmittance, scattering...) The rest are different. Bump, roughness, normals etc are value maps and they are not gamma corrected of course. Neither the ones you use for illumination (hdr, exr...).

[dmeyer]

Input conversion is only for color textures (reflectance, transmittance, scattering...) The rest are different. Bump, roughness, normals etc are value maps and they are not gamma corrected of course. Neither the ones you use for illumination (hdr, exr...).

Right but is there any way to disable this conversion for color textures? Does it do some sort of detection to see if it is necessary or does it apply always?

I am asking because we are building a workflow that includes artwork from illustrator, as well as manually linearizing photographic textures.

[tom]

Gamma is hard-tied to input color space and currently it's sRGB. As you know sRGB gamma is 2.2 so, that's why it assumes all given textures in this color space. If you give more details about your workflow then I can shed more light maybe.

[zdeno]

You have to go back to beta version or one of RC# (i am not sure witch one was that) there was opportunity to set own gamma for textures.

Now it is gone.

Mayby it would be nice to have some hidden "expert mode" to use that again ? then new users would have it's safe automat, but people who knows what they are doing could have some fun.

for this day looks like fastest way is batchprocess all 1.0 gamma color textures to 2.2 (I don't know if this conversion is datalost (corrupt color information with 1.0-2.2-1.0 conversion) or completely reversable.

[dmeyer]

Gamma is hard-tied to input color space and currently it's sRGB. As you know sRGB gamma is 2.2 so, that's why it assumes all given textures in this color space. If you give more details about your workflow then I can shed more light maybe.

For sake of this post, assume I am not at all referring to surface textures such as bump, disp, etc as those appear to be not affected by the inverse 2.2 adjustment.


For product or package visualization we will often get many variations of artwork designs in CMYK Illustrator format, with of course "white" as the negative space.

When these are rasterized to RGB you end up with an uncalibrated "linear" image but that includes white as the "not printed area."

We will then create a mask for this unprinted area using Photoshop - so we do not have the negative space "white" reflecting energy in the scene.

The MXM is then created with several layers. The printed "media" layer (box, shirt, paper, whatever) and then the artwork on top decal style.

Top Layer (masked with clip map from white space in artwork file)
Artwork BRDF <- currently input as raw rastered file from Photoshop, assuming gamma 1.0
Bottom Layer
Paper BRDF <- may have reflectance textures obtained with scanner or camera that currently are likely input with 2.2, thus are 'corrected' by maxwell.




Assuming my above assumtions are correct, the options are:

1. We should be applying 2.2 gamma to the artwork so that when Maxwell does the 2.2 inverse it will be correct, it has been under gamma'd all along.
2. If Maxwell were to allow disabling of 2.2 inverse gamma, we would then make sure any captured textures input into the Paper BRDF were linear.


With option 1, if we use 16 bit depth, is the gamma operation reasonably lossless?