Page 1 of 2
Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 11:15 am
by boris
Jim and all 3ds max plugin Users
I would like to bring up the gamma discussion up again.
I am pretty sure other users think the same or similar as me.
I stayed with the 2.13 version since for me the new gamma implementation just feels wrong and I just can't work with it.
here my experiences WHY:
- Opening an old scene and trying to get the same render result only works when I completely disable 3ds max gamma. You see that, too, do you?
Maybe I can change the gamma again when saving the framebuffer but that's not what I wan't since octane is all about interactivity: I wan't to see what I get - and it must look nice
- Using any tonemapping curves other than linear with 3ds max gamma 2.2 enabled leads to overbrighted results.
I wonder how you other users come along/work with the new gamma implementation?
I am working with 3ds max since 17 years now and have over lived and worked with many render systems and I really tried but I am just not happy with the new gamma system.
It might be correct in Jim's eyes (and I am sure it is) but I still believe there must be a more intuitive solution.
Am I the only one here?
And Jim: no offense at all, you are doing a great job here as always.
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 11:28 am
by boris
Just to collect some information from the plugin release posts:
JimStar wrote:
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.
then Jim's explanation with images:
viewtopic.php?f=80&t=52130
notice that these images are all rendered with linear response. see the camera settings to the right:
download/file.php?id=48960&mode=view
for me it seems pretty clear now:
- to use octane's response curves you have to disable 3ds max gamma and get a bad viewport/material editor feedback of your maps/materials
do you all work with linear response curve now?
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 7:19 pm
by JimStar
boris wrote:- to use octane's response curves you have to disable 3ds max gamma
This is wrong statement. I've never said it. You need to set
Octane imager gamma to 1.0 to use response curves, not 3ds Max gamma - I explained this already in previous topics.
Will try to explain one more time here.
Yes, the only problem that still remains in current 2.X plugin versions regarding gamma - a camera responses can only be used when gamma 1.0 is set
in Octane imager. I already wrote about it in my previous explanations: this is not a plugin issue, this is a bug in Octane tonemapping core, standalone renders the gamma incorrectly too when camera responses are used with gamma other than 1.0 (I found it when this problem was reported previously in plugin's topics).
Unfortunately the fix was not released neither in 2.25 core nor even in 3.0 alpha 4 - I only see the fix is present in 3.0 alpha 6.
So as I wrote before - the workaround is easy: when you have set a camera response to anything but "None", just set the Octane imager gamma to 1.0 and 3ds Max gamma to any gamma you need. 3ds Max allows you to save the rendered image in
any other gamma if you need it.
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 7:44 pm
by daniel.reutersward
I must be stupid...I still can´t get it to work?
Image 01: With 3Ds Max gamma on default 2,2 and gamma 1,0 in Imager settings I get double gamma?
Image 02: With Linear response curve I get correct gamma.
Image 03: Disabling 3Ds Max gamma gives me correct gamma when using a response curve?
I have set gamma to 1,0 in the imager and I still don´t get a correct result when using the 3Ds Max Gamma that I want?
EDIT: They are in the wrong order but the file comment above the images displays the correct number. So it starts with Image 03.
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 7:59 pm
by daniel.reutersward
Also here is a test I posted earlier showing that something is wrong.
The Octane Render version is with the new gamma settings in the plugin.
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 8:32 pm
by daniel.reutersward
To elaborate on this:
In Plugin version 2.11 with 3Ds Max gamma set to 2.2:
When using Linear response curve you have to change the Imager gamma to 2.2 otherwise it won´t look correct.
Other response curves such as "Agfacolor_Futura_100CD" looks correct with Imager gamma at 1.0.
In Plugin version 2.21 with 3Ds Max gamma set to 2.2:
When using Linear response curve you don´t have to change the Imager gamma to 2.2. Imager gamma at 1.0 looks correct.
Other response curves such as "Agfacolor_Futura_100CD" need gamma 1.0 to work correctly, but they are getting 2.2 right away.
So somewhere there is too much gamma?
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 11:09 pm
by JimStar
3ds Max gamma settings define how the image (stored in render buffer) is presented on your display. It doesn't change anything regarding render buffer itself.
So, if e.g. you've asked Octane core to render for you the image and tonemap it "in place" (which BTW takes additional GPU resources during rendering) with some gamma and/or response curve - the gamma you've set in 3ds Max settings it applied on top of the rendered image (stored in 3ds Max image buffer) before showing you this image on your monitor.
So, if e.g. some Octane core camera translation tables make the render result brighter - you can easily overbright it on your display if you set the 3ds Max gamma value too high...
But this is the correct sequence: first the camera response curves must be applied to the raw (1.0 gamma) render result, and only after that the additional gamma correction can be done if needed. Otherwise the tonemapping result will be irreversible for such (even HDR) image - you will not be able to reapply any other gamma to the rendered image if the camera's response curves (that are highly non linear) were applied to the image after the gamma correction. In this case it is impossible to e.g. reverse this gamma correction to get back this same image but with gamma 1.0.
So, in short, if you have set some response curve in Octane imager - you always have exactly this result stored in 3ds Max image buffer regardless of what gamma value is set in 3ds Max settings (this is how 3ds Max works with gamma), and you can save the image from this buffer "as is" or, if Octane imager gamma was set to 1.0 - with any other gamma on top of it. But 3ds Max will display it on your monitor with gamma set in 3ds Max settings applied on top of the render buffer.
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Tue Apr 05, 2016 11:19 pm
by daniel.reutersward
Thanks for the reply JimStar!
I think I understand, basically 3Ds Max adds gamma on top of the already applied gamma?
What I don´t understand is how this could work before?
No matter how much I try I always end up with 2 options:
1. Disable 3Ds Max gamma and get correct image in Octane Viewport, but incorrect Material Editor Previews.
2. Enable 3Ds Max gamma and only use Linear response curve and apply color grading in PS, basically revert to my very old workflow.
Or am I missing some combination of settings?
I´m really slow when it comes to understanding this!
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Wed Apr 06, 2016 8:05 am
by boris
JimStar wrote:boris wrote:- to use octane's response curves you have to disable 3ds max gamma
This is wrong statement. I've never said it. You need to set
Octane imager gamma to 1.0 to use response curves, not 3ds Max gamma - I explained this already in previous topics.
Will try to explain one more time here.
Yes, the only problem that still remains in current 2.X plugin versions regarding gamma - a camera responses can only be used when gamma 1.0 is set
in Octane imager. I already wrote about it in my previous explanations: this is not a plugin issue, this is a bug in Octane tonemapping core, standalone renders the gamma incorrectly too when camera responses are used with gamma other than 1.0 (I found it when this problem was reported previously in plugin's topics).
Unfortunately the fix was not released neither in 2.25 core nor even in 3.0 alpha 4 - I only see the fix is present in 3.0 alpha 6.
So as I wrote before - the workaround is easy: when you have set a camera response to anything but "None", just set the Octane imager gamma to 1.0 and 3ds Max gamma to any gamma you need. 3ds Max allows you to save the rendered image in
any other gamma if you need it.
what I meant by that is best explained by looking at the picture #1 from daniel above. the image in the framebuffer has the correction from Agfacolor_Futura_200CD (which is basically something like a correction from gamma 1 to 2.2 and on top of it the 3ds max gamma correction from 1 to 2.2 again. I agree that this is basically the correct gamma pipeline and I KNOW that NOW he could set 3ds max gamma to 1.0 (means: disable it) or override the gamma while saving but that is exactly the problem: the visual feedback. Me as user does not want to switch between 3ds max gamma 1 and 2.2 while working on a scene.
At the moment I do not see any solution for me than doing exactly that: switching between 3ds max gammas. this of course only if I want to use octane's tonemapping and have a usable gamma correction on the interface.
Ideally the user (or the plugin) should be able to control the gammas of the interface viewport and the material editor independently and those should have no effect on the render viewport stored gamma. But Jim stated that in current 3ds max SDK this is not possible.
Re: Gamma Implementation since Plugin V. 2.14 feels unintuitive
Posted: Wed Apr 06, 2016 8:11 am
by boris
daniel.reutersward wrote:Thanks for the reply JimStar!
I think I understand, basically 3Ds Max adds gamma on top of the already applied gamma?
What I don´t understand is how this could work before?
!
It looked like it worked but it was some kind of a fake and for sure not correct...
edit: here the gamma pipeline from mentalray:
http://docs.autodesk.com/3DSMAX/15/ENU/ ... 61-low.png
this represents a "clean" gamma pipeline. Jim's problem and probably all render plugin developer's is to integrate the the 3ds max gamma correction into the octane pipeline without getting wrong saved gammas which you have to understand to not get confused.
