Exposure changes after re-rendering (But how to lock exposure?)

[OccultMonk]

When I change exposure in tone mapping in the VFB window after rendering has started I get a different result when re-rendering. This seems to be caused by the Max sample intensity (MSI) parameter. But I don't understand how I can adjust the exposure during render without it changing again when I re-render.

Now the only solution is to set exposure each time I re-render to 1.0 and only after rendering has begun change the exposure back. This seems a strange way of working. Am I missing something? How should I lock the exposure so it does not adapt to the changes after re-render?

The problem seems to be described here, but no solution:

https://coronarenderer.freshdesk.com/support/solutions/articles/5000517899-exposure-changes-when-i-start-rendering-

[ArchSpideR]

lighting with hdri via coronaoutput?

[OccultMonk]

lighting with hdri via coronaoutput?

Yes, I Use Corona Scene Environment Overwrite.

[ArchSpideR]

turn on

[OccultMonk]

Thanks, but I can't find the setting in Corona 1.7 RC3.


I have a few other questions:

Why is this turned off by default? Is this only a problem with HDRI lighting?

I would expect the exposure to only influence the postfix and not the rendering. Why is this?

Is there a better way of changing the exposure than in the VFB settings?

[OccultMonk]

Anyone? I can't get the exposure stable. It keeps adapting to the new render.

[OccultMonk]

Sorry to bump this up again, but some information would be really helpful. This issue makes adjusting exposure very difficult, and I think I am overlooking something.

[maru]

Sorry for the delay. I had this thread on my todo for some time, but as usually there is a lot of work before the release and the Corona Academy.

If you are indeed loading your HDRI through CoronaOutput map as ArchSpideR suggested, then the solution would be simply to enable the "affected by tonemapping" option. In such case, the changes would be by design, because Corona would be doing its best to change the HDRI so that it is not affected by the tonemapping parameters, resulting in different scene lighting.

If you are not using the CoronaOutput map, then the changes are because of MSI, and that is explained in the article you linked in the 1st post. This is expected as well, and the only way to get rid of this behavior is to set MSI to 0, which unfortunately will most likely introduce a lot of noise.

Why is this an issue anyway? Are you doing some renders that require perfect exposure reproduction? Could you post examples?

[OccultMonk]

Thanks, That solved it. But I do not understand why you would want this OFF by default. That means that every time you adjust the exposure, the renderer will auto adjust again when rendering with a HDRI map. Having this on by default would make more sense.

[maru]

Thanks, That solved it. But I do not understand why you would want this OFF by default. That means that every time you adjust the exposure, the renderer will auto adjust again when rendering with a HDRI map. Having this on by default would make more sense.

Do you mean having MSI set to 0? The most serious drawback of this would be a lot of fireflies in some cases, and much longer render time to get a clear image. In some cases, the fireflies could virtually never go away.

[Nik]

He is talking about "Affect tonemapping" in CoronaOutput being off by default. And I agree, this is confusing.
I know at least one man who leaved this option in default state and get incorrect results. He actually didn't see any problems until he changed postprocessing settings.
Some people think that CoronaOutput is colorcorrection map, not a map to bypass tonemapping.

And that's why I believe this setting should be enabled by default.

[Ondra]

Hi,
we know about this being a problem, and the solution is to split the map in two for 1.8 release - one just for the checkbox, other one for all the color adjustments. We did not have time to do this for 1.7, because we will need to support also loading legacy scenes, which in this case is not straightforward

[OccultMonk]

Hi,
we know about this being a problem, and the solution is to split the map in two for 1.8 release - one just for the checkbox, other one for all the color adjustments. We did not have time to do this for 1.7, because we will need to support also loading legacy scenes, which in this case is not straightforward

I do not really understand this. Is that backward compatible?

[maru]

It means that this will be improved in Corona Renderer 1.8, but it requires careful planning and some work.

[Juraj]

Not sure how backwards compatibility will be done, but that's the right decision.

Right now it's full on post-processing node with incorrect default state for almost unrelated function. It will become really great alternative to slow and limited ColorCorrection node.