OTOY Forums

If you run the material converter on a standard material with an opacity map, a couple bad choices are made:

1. The gamma is set to 2.2, when it should be 1
2. A tif image which is set to mono channel output=alpha in the standard material is imported as an Octane RGB map, when it should be an Octane alpha map. This should be checked for tga, and png files as well.

The bump maps also get imported with gamma of 2.2, though at least the converter chooses an Octane greyscale image.

Hi senorpablo,
could you share a standard material before converting to Octane?
Regards
Paride

paride4331 wrote:Hi senorpablo,
could you share a standard material before converting to Octane?
Regards
Paride

See attached.

Hi senorpablo,
a correct conversion replace RGB image node with alpha image node.
Gamma is ok. Developers will fix it in next release.
thanks
Paride

paride4331 wrote:Hi senorpablo,
a correct conversion replace RGB image node with alpha image node.
Gamma is ok. Developers will fix it in next release.
thanks
Paride

The gamma for any map other than diffuse should not be anything other than 1 by default. This includes: bump, displacement, emission, alpha, etc. If the gamma is 2.2, values which are meant to be half(0.5) get converted to 0.21.

In your comparison, you can see that the alpha map in the Octane version is contracted compared to scanline. The needles are smaller and thinner! This is because the gamma is improperly set to 2.2, rather than 1.0. It's not correct. The material converter should set the gamma to 1.0 for every map except diffuse.

Hi senorpablo,
I do not agree, it makes sense to use gamma 1 with 32bit image, but not using 8bit jpg files.
Regards
Paride

Hi senorpablo,
I do not agree, it makes sense to use Gamma 1 with 32bit image, but not using 8bit jpg files.
it could make sense octane automatically sets Gamma 1 by importing 32bit image.
Regards
Paride

Hi senorpablo,
I do not agree, it makes sense to use Gamma 1 with 32bit image, but not using 8bit jpg files.
it could make sense Octane automatically sets Gamma 1 by importing 32bit image.
Regards
Paride

paride4331 wrote:Hi senorpablo,
I do not agree, it makes sense to use Gamma 1 with 32bit image, but not using 8bit jpg files.
it could make sense Octane automatically sets Gamma 1 by importing 32bit image.
Regards
Paride

I'm not sure what the bit depth of the image has to do with it. While it is generally true that 16 bit and above images are assumed to be in a linear color space, that does not preclude that 8 bit images can also be linear. Think about it: any map other than diffuse, you would generally want to be gamma 1.0 so that .5 = .5, .25 = .25, and so on. Normal maps especially. I can't think of a single case where you would want utility maps to be anything other than 1.0 as a default.

This is another illustration why. A a linear gradient(0..255) as a displacement: On the left is an 8 bit jpg. Middle is a jpg gamma corrected manually to 2.2. On the right is a 32 bit tif.

Gamma is disabled for displacement maps, the parameter has no effect. The middle image is what you get when you set the opacity map to an incorrect gamma of 2.2. It's not a straight line! On the left is gamma 1.0--correct just like the 16 bit image at gamma 1.0 on the right. Bump maps, opacity maps, normal maps and everything else other than diffuse would suffer this same issue.

By the way, you can see here that there is some goofy math going on in Octane with images or displacements as that angled line should be perfectly straight for the two end displacements, but they're not. Instead, there is a slight s-curve.

Hi senorpablo,
put my two cents in, Octane is spectral not rgb, but unless you only work with 16bit and 32bit files and have HRD monitors, set everything to gamma 1 there's not much sense to.
I personally consider gamma editing in a more creative way, adjusting it in the textures according to the needs; except for hdri files.
normal as displacement works indifferently with gamma 1 or 2.2
Regards
Paride