Problem with Lights Kelvin and VFB White Balance

[racoonart]

Count me in for going back to how it was. I was just wondering why my renderings look strange and stumbled upon this thread just in time.

[Ondra]

Don't worry, we are alive. Just dealing with a lot of stuff at this moment.

What happened in 1.4 in tone mapping:
exposure -> white balance -> highlight compression

what happens in 1.5:
exposure -> highlight compression -> LUT -> white balance

LUT has to be applied after highlight compression, because it assumes 0-1 inputs, which highlight compression usually provides. We moved white balance (both kelvin temp and color tint) at the end of tone mapping chain so both can be used to apply final look to the image, after LUT. LUTs provide certain predefined color look that users might want to tweak further, so it makes sense to do white balance after LUT.

What we did not count on was that when user uses kelvin temp to counter-balance kelvin-temp of light together with HC, what happened in 1.4 was:

light kelvin temp -> inverse(light kelvin temp) -> white image -> highlight compression -> still white image

what now happens in 1.5:

light kelvin temp -> highlight compression -> inverse(light kelvin temp) applied on image already changed by higlight compression, not the original image -> non-white image


so the solution would be to move the white balance (K) at the beginning of the chain, and leave only color tint at the end after LUT. This would however again change the look of images (back to 1.4), so we cannot release this as 1.5 hotfix - it will have to be released in 1.6, starting with daily builds

[Nik]

Why "exposure -> WB -> highlight compression -> LUT" could change the look of old 1.4 images?
If I don't use lut and color tint then image should be the same. No?

[alexyork]

so we cannot release this as 1.5 hotfix - it will have to be released in 1.6, starting with daily builds

:(

In my opinion, 1.5 has only been out a very short time, and it seems that it's only in the final 1.5 release not in all of the previous dailies and RCs... Short enough time like this to be able to revert so that people are getting the exact results they are expecting. I would presume that 1.6 final release is quite a way away for those who don't want to move their whole pipeline over to a daily build. I mean it's up to you guys of course but if this is the decision then it might mean we need to skip 1.5 entirely, which would be a shame as we're super keen to get using all the new post tools and other benefits!

[Dionysios.TS]

Don't worry, we are alive. Just dealing with a lot of stuff at this moment.

What happened in 1.4 in tone mapping:
exposure -> white balance -> highlight compression

what happens in 1.5:
exposure -> highlight compression -> LUT -> white balance

LUT has to be applied after highlight compression, because it assumes 0-1 inputs, which highlight compression usually provides. We moved white balance (both kelvin temp and color tint) at the end of tone mapping chain so both can be used to apply final look to the image, after LUT. LUTs provide certain predefined color look that users might want to tweak further, so it makes sense to do white balance after LUT.

What we did not count on was that when user uses kelvin temp to counter-balance kelvin-temp of light together with HC, what happened in 1.4 was:

light kelvin temp -> inverse(light kelvin temp) -> white image -> highlight compression -> still white image

what now happens in 1.5:

light kelvin temp -> highlight compression -> inverse(light kelvin temp) applied on image already changed by higlight compression, not the original image -> non-white image


so the solution would be to move the white balance (K) at the beginning of the chain, and leave only color tint at the end after LUT. This would however again change the look of images (back to 1.4), so we cannot release this as 1.5 hotfix - it will have to be released in 1.6, starting with daily builds

Ondra, you're alive!!! :D

Thanks for getting back and for the explanation, hope this problem is going to get fixed soon and please guys, tone mapping and a good VFB is one of the most important tools in the engines today, don't screw things up! :)  Take a look at Fstorm, they have a sweet output all those images there...

[Nik]

so we cannot release this as 1.5 hotfix

The simple fact is - if Corona 1.5 will keep this colormapping mode - this version will be fu*ked up.
Many users could ignore it.

1.5 have so much good features like PBR, LightMixer, Glares, but colormapping and lack of backward compatibility can ruin it.
Please, think twice when you make this decision. It can affect the reputation of Corona as render engine.

[Juraj]

Why "exposure -> WB -> highlight compression -> LUT" could change the look of old 1.4 images?
If I don't use lut and color tint then image should be the same. No?

Same understanding here :- ). Dubcat might be unhappy but if this is the only way it works correctly than this would work.

And no one uses tint, at all. This is not how the feature should work. It should either be bundled with WB like AdobeCameraRaw has it, or it should be color-picker to counter-balance color. As it is it does not need to be there or taken into consideration, 99,9 perc. no one is using it.

[Ondra]

Why "exposure -> WB -> highlight compression -> LUT" could change the look of old 1.4 images?
If I don't use lut and color tint then image should be the same. No?

there are 2 things:
1) whay ways the order of operations changed? Because we added LUT that has to be applied after HC, and we wanted color balance to be applied after LUT. Which implies color balance being applied after HC

2) why this changes look of images? Because temperature in color mapping is inverse of temperature in lights, and inverse_function( function( x ) ) == x. But when we add HC in the middle, inverse function no longer gets original function output, so it cannot invert it: inverse_function ( another_function ( function ( x ) ) ) =/= x. Unless you use HC/contrast/filmic/LUT, white balance should work as before

[pressenter]

Hi guys,

I'm not hundred percent sure so just to clarify: this tone mapping change took place between the last RC and final release of 1.5?

If so I am with Alex on this one. 1.5 was released one week ago, doubt it that anyone managed to start and finish a project in that time, but it definitely is affecting our running projects. We will have to downgrade to RC and wait for 1.6 final, without the possibility to use and test all the daily features that will come out in the meantime, just so that we can maintain the look of our currently running projects, which basically means that from this point on we will never be able to upgrade. Is there something we can do to get around this?

Best
Simon

[Ondra]

no, it was present in daily builds before RCs

[DKulakov]

I have not started new projects and really looking forward to an amended version!

[Juraj]

Why "exposure -> WB -> highlight compression -> LUT" could change the look of old 1.4 images?
If I don't use lut and color tint then image should be the same. No?

there are 2 things:
1) whay ways the order of operations changed? Because we added LUT that has to be applied after HC, and we wanted color balance to be applied after LUT. Which implies color balance being applied after HC

2) why this changes look of images? Because temperature in color mapping is inverse of temperature in lights, and inverse_function( function( x ) ) == x. But when we add HC in the middle, inverse function no longer gets original function output, so it cannot invert it: inverse_function ( another_function ( function ( x ) ) ) =/= x. Unless you use HC/contrast/filmic/LUT, white balance should work as before

Adding WB as last step looked sound on paper. But if it's technically not working to what artists expect, and it definitely doesn't (since 2) everyone does use HC mostly) than it's totally OK to scratch it and forget it.

[Nik]

Just put LUT at the end of chain and make 1.5 hotfix. That's it. Forget about tint.

I'm not sure but I suppose there are no strict rules for LUT in renders. Even for video I can put LUT in different order and get different results but othen there are no "right" place for it. I mean artistic LUTs

[Ondra]

we will release it in first daily build after 1.5. It will be called 1.6 daily build, but this will be the only change. 1.5 was installed on too many computers to change the behavior, we cannot "erase" it from the history now.

[Nik]

All people made mistakes, why you don't want to make hotfix? You did that before, if my memory is fine
In 1.6 people will butthurt because scenes from 1.5 don't look the same. Never ending story. Hotfix is the solution that all should like