Gamma Correction in maps for monochrome maps

[3dwannab]

Please try the same with the ColorCorrect Map from Cuneyt Ozdas (get the link from maxplugins.de), I seem to remember this worked fine there.

AFAIR the underlying problem is that color and bump are handled independently through different channels and maps that are designed to do color transforms will work only on the color channel and dismiss bump. Hence the bump amount paramter in the maps output controls, that's the only one affecting bump. It would be great if this would be finally changed but then again they should update and improve the whole output/CC section.

Thanks for the suggestion. I did try that before. See screenshots of proof.


The relief on the white values differs greatly from the black values if you notice using 2.2 gamma. Should this not be the same regardless of how 3ds max interprets a bump bitmap? These values are opposite ends on the scale. But it's probably due to the fact the 128,128,128 RGB grey value is getting shifted.

Anyway nothing seems to work with changing the gamma outside of overriding in the loader. Which is a horrible way to control it.

I agree Juraj. Just because this problem lies in VRay, mental ray etc doesn't necessarily need to be the case with the Corona Shader.

Maybe I'm wrong?

[Ludvik Koutny]

I did not read through the entire thread properly, but from the pieces I have read and put together, I don't see anything wrong in here. Bump maps fall into the group of maps, that should be loaded with 1.0 gamma - like with normal map. Some maps should be loaded with gamma 2.2, while others should be loaded with gamma 1.0. I agree it's a bit of mess, but it's not a mistake on Corona's side, nor on 3ds Max side. It's just a legacy mess that was always this way.

It's basically a difference if the input data is supposed to be displayed on monitor and read by human eye, or fed to a mathematical algorithm to be crunched. If it's data for the eye, like in case of diffuse map for example, it should be gamma 2.2. If it's data to be crunched by mathematical code, and used to create some other effect, like bump map, which is basically a height map, then the input data should be without gamma curve - therefore 1.0. The messy part in here is that sometimes is not completely clear which of the two categories given map falls into, such as reflection maps for example.... So you often stumble upon each texture painting/sculpting software doing it it's own way, and you have to figure it out by experimentation.

[3dwannab]

3ds Max has no buit-in:
a) bump mapping support
b) gamma control support

and normal mapping shader is expected to load sub-maps with properties a) and b). This makes the implementation a bit... weird.

So no implementation of http://help.autodesk.com/view/3DSMAX/2015/ENU/?guid=__files_GUID_82742687_1173_40C5_BDDE_7B5AE010DD80_htm could be added to the Corona Bitmap map?

This would allow us script something like:

Code: [Select]

theCoronaBitmaps = (getClassInstances CoronaBitmap)
for m in theCoronaBitmaps where m.gammaMapValue != 1.0 then (
    for m in theCoronaBitmaps do (
        m.gamma = -1.0
    )    -- set to auto gamma
)
gammaMapValue is just a made up variable

This would change any  bitmap where gammaMapValue value is not 1.0 to #auto gamma.

This way you could easily manage the value outside of the loader method which sucks.

[Ondra]

3ds Max has no buit-in:
a) bump mapping support
b) gamma control support

and normal mapping shader is expected to load sub-maps with properties a) and b). This makes the implementation a bit... weird.

So no implementation of http://help.autodesk.com/view/3DSMAX/2015/ENU/?guid=__files_GUID_82742687_1173_40C5_BDDE_7B5AE010DD80_htm could be added to the Corona Bitmap map?

This would allow us script something like:

Code: [Select]

theCoronaBitmaps = (getClassInstances CoronaBitmap)
for m in theCoronaBitmaps where m.gammaMapValue != 1.0 then (
    for m in theCoronaBitmaps do (
        m.gamma = -1.0
    )    -- set to auto gamma
)
gammaMapValue is just a made up variable

This would change any  bitmap where gammaMapValue value is not 1.0 to #auto gamma.

This way you could easily manage the value outside of the loader method which sucks.

well... you would think that would work, but what if you have 2 different bitmaps with different gammas in one slot? What if one of the maps is also in diffuse slot where you want it with different gamma? ;)

[3dwannab]

Bit confused by that. If I evaluate

theCoronaBitmaps = (getClassInstances CoronaBitmap)

in a scene with only 4 different .tif files, the result is an array like:

#(Map #29:Veg - Leaf Beech #001_acer_saccarinum_leaf1_DIFFUSE.tif, Reflect:CoronaBitmap, Map #37:CoronaBitmap, Norm:CoronaBitmap, Map #60:CoronaBitmap, Map #29:Veg - Leaf Beech #001_acer_saccarinum_leaf1_DIFFUSE.tif, Reflect:Veg - Leaf Beech #001_acer_saccarinum_leaf1_SPECULAR.tif, Map #37:Veg - Leaf Beech #001_acer_saccarinum_leaf1_DIFFUSE.tif, Norm:Veg - Leaf Beech #001_acer_saccarinum_leaf1_NORMAL.tif, Map #60:Veg - Leaf Beech #001_acer_saccarinum_leaf1_DISP.tif)

So if I use a script like in the above post it'll ignore and maps where the gamma spinner value in the corona bitmap == to 1. so you can't possibly mess up anything. Maybe I didn't understand you correctly. ;] And if you want different gamma then on the same bitmap then you simply copy that and change the gamma in the spinner. This way you always keep loading the bitmaps as auto gamma and change it after the fact which in turn will change the maxes loader value.

I don't know why Autodesk implemented the gamma overrides where they did anyway tbh. They'd be better off placed in the bitmap map.

I just think having some sort of gamma control in the Corona Bitmap would be a great asset to have. Not sure if that's something you would like to implement though?