ka-ra wrote:Same bug here.
It is not a bug.
Read my explanations here please. Use
3ds Max gamma to see the rendered image in any needed gamma
in 3ds Max user interface. If you disable 3ds Max gamma - the rendered image will be shown by 3ds Max "as is" from its bitmap-buffer holding the render-result.
This is how 3ds Max gamma processing works. When showing the rendered image in user interface the render-buffer is always recalculated by 3ds Max to gamma set in its gamma settings, no matter what gamma correction is already applied to the image in render-buffer. Think of it as
major gamma correction setting
for 3ds Max user interface display, which is above the setting of Octane Imager. The only advantage of setting gamma in Octane Imager if you have 3ds Max gamma enabled is: when Octane Imager gamma and 3ds Max gamma are
the same - there are no processor resources spent to recalculate gamma before displaying the image in 3ds Max user interface.
No matter what Octane Imager gamma is set - the non-HDR image can be always saved with any needed gamma, so again, there is only matter of some processor resources spent on gamma recalculation during saving. "Automatic" will save it as is (with Imager gamma). The HDR images are saved by 3ds Max from render-buffer
as is - that is with gamma which is in render-buffer (which had been set in Octane Imager).
The only one issue so far which can't be fixed right now (but has a simple workaround).
This is exactly the reason why you see the rendered image in correct 2.2 gamma in 3ds Max user interface when 3ds Max gamma is set to 2.2 and Octane Imager has gamma 1.0 when non-Linear camera response is set, and you get the over-brighted image as soon as you change Octane Imager gamma to 2.2 not changing anything else.
I've checked the Octane core engine code and found a tonemapper bug in there which happens when both "camera response is non linear" and "gamma is not 1.0" is set in Octane Imager. This bug affects both Octane standalone and Octane plugins. This is why in this particular case the image becomes slightly over-brighted both in a standalone and in a plugin with such settings in Imager, and this image can't be correctly recalculated to any other gamma. You will see the same result both in a plugin and in standalone, 'cause they both use the same Octane rendering engine.
I've fixed this in Octane trunk, so the next 3.0 alpha will have the correct tonemapping in this particular case. But I'm not sure if there are any other 2.X SDK releases planned...
But the workaround of this in a plugin is easy: if you have gamma 1.0 set in Octane Imager - the tonemapping result is always correct, no matter what camera response curve is chosen (and it can be correctly recalculated by 3ds Max to any other gamma). And you are still able to save the rendered image from 3ds Max with any gamma needed - 3ds Max just applies to it the gamma correction you've chosen when saving.