Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] Bug Reporting => [Max] Resolved Bugs => Topic started by: Dionysios.TS on 2016-10-07, 18:52:14
-
Hi guys, I noticed something weird and not correct IMHO.
Here are the steps:
1. Create a Corona Light and set Kelvin color to 3.500
2. Render and in the VFB set White Balance Kelvin to 3.500
Result: The light's color has a bad coloration in general and is not white as it should be. The lighted surfaces have not a correct contrast and highlights and the image seems darker.
Now do this:
1. Create a Corona Light and set Kelvin color to 5.000
2. Render and in the VFB set White Balance Kelvin to 5.000
Result: Much better and lighting seems more efficient!
So, In the first case, it should be the same result as in the second one as the White Balance has the same K values. But is not like this, actually it seems that using warm K values the light is a bit altered.
I attached some very fast test for this.
What do you think?
Thanks,
Dionysios -
-
Corona 1.5?
-
Yes, didn't tried with 1.4
-
It's a new colormapping procedure order in 1.5.
I told devs that something wrong with colormapping in 1.5 RC but they disagreed
-
My nights shots or daylight + ies lights shots look weird! -.-
-
My also. Wait for corrections?
-
My also. Wait for corrections?
Same results!!! The lights seem to have a strange weak strength which I don't like at all unfortunately.
1.4 worked better in this case.
-
1.4 worked better in this case.
Definitely!
-
Another example.
-
Primary lighting gives a blue tint 1.5. Fix it please.
-
Thanks for posting the example. I am having this issue without using filmic highlights too... When the light's Kelvin is warm (3.000 / 3.800) the strength and color produced is weird whatever highlight's compression method is used.
-
Aaaaaand?
-
Aaaaaand?
I don't know...
Didn't received any new from the team yet. I also started another post the same day I started this one about some issues with IES file in Corona, but still no news.
-
I did play with white balance and I think I could replicate it. Actually anything else than pure 6500K looked bit odd. Decided to do WB only in Photoshop in meantime.
-
Yes, really strange!
-
Any explanation will be given to whether???
-
Comparsion of Corona 1.5 daily vs 1.5 release is attached
-
That's not looking good at all.
-
Hope this can be squashed in the next couple of weeks. We're planning on upgrading our pipe to 1.5 as soon as some large jobs are out of the way but this looks like a show-stopper to me. Hopefully relatively simple to sort...
-
That's not looking good at all.
Guys, are you ok? (dev team) Any news here??? This is an important issue and would be nice to know what you think about it.
Thanks,
Dionysios -
-
I can confirm the same issue. I have literally hundreds of files with furniture product shots, which now render in a completely different tone than in 1.4. Which means I have to revert our whole render farm back to 1.4 now because I have no time to second guess and try adjusting more than a thousand images to look the same as the ones we already sent out.
I just rendered one and for a moment I thought I was crazy, then I found this thread...
-
I can confirm the same issue. I have literally hundreds of files with furniture product shots, which now render in a completely different tone than in 1.4. Which means I have to revert our whole render farm back to 1.4 now because I have no time to second guess and try adjusting more than a thousand images to look the same as the ones we already sent out.
I just rendered one and for a moment I thought I was crazy, then I found this thread...
Is good to know I am not the only crazy here but more people are producing these results.
Something is worong in general with the White Balance + Tone Mapping process.
-
I don't know when Ondra will post a message here, so I dare to copy some of his answers from Skype.
[2016.10.15 17:10:09]
me: Ondra, hi.
Many people still waiting for any explanation of this behavior.
ondra.karlik: it was already explained, color correct is now applied after highlight compress. Not sure if we want to change the behavior again (back to 1.4)
me: https://forum.corona-renderer.com/index.php/topic,13377.15.html
This topic needs for your attention.
Users want Corona tonemapping to be perfect as before. LUTs are nice, but WB is more important
ondra.karlik: we will discuss it internally next week
So we're all can sit back and relax for a while. Maybe it will be fixed. Maybe not
-
Oh... Well, given a choice I'd prefer it to just be the same as before. If we have to lose LUTs or something because of that - so be it, since otherwise this would mean none of the god-knows-how-many scenes I've done in the last year or so won't render correctly anymore. And that's a mess of epic proportions, for me at least. I have to go back to finished projects for some new angles and whatnot quite often.
-
Oh... Well, given a choice I'd prefer it to just be the same as before. If we have to lose LUTs or something because of that - so be it, since otherwise this would mean none of the god-knows-how-many scenes I've done in the last year or so won't render correctly anymore. And that's a mess of epic proportions, for me at least. I have to go back to finished projects for some new angles and whatnot quite often.
For what it's worth we are in the same boat, as are many I would guess. We're very often revisiting old projects when clients want new images etc. We need to ensure that we can open and re-render with minimal if any differences. Hopefully this is a relatively simple fix by way of a switch or warning when you open a max file saved in anything earlier than 1.5 final with a conversion available if needed.
-
It probably could be adjusted because in VFB+, I could have LUT, Tonemapping and WhiteBalance working correctly at same time, neither clamping each other.
Currently the WB is rendered unusable, because only no WB (6500/White) renders correct image. Everything else is like white-balancing clamped jpeg.
I don't see why this is LUT vs WB, both can work correctly together just fine, as illustrated by VFB+ .
-
I don't know when Ondra will post a message here, so I dare to copy some of his answers from Skype.
[2016.10.15 17:10:09]
me: Ondra, hi.
Many people still waiting for any explanation of this behavior.
ondra.karlik: it was already explained, color correct is now applied after highlight compress. Not sure if we want to change the behavior again (back to 1.4)
me: https://forum.corona-renderer.com/index.php/topic,13377.15.html
This topic needs for your attention.
Users want Corona tonemapping to be perfect as before. LUTs are nice, but WB is more important
ondra.karlik: we will discuss it internally next week
So we're all can sit back and relax for a while. Maybe it will be fixed. Maybe not
Thanks for the info I hope they can resolve in a way some things here. Other engines offer better tone mapping controls for now and I hope this issue will be taken seriously.
-
It's not just a problem of backward compatibility anymore.
In brand new scenes user can't get good tonecompressed image with low white balance. There is no way to do that in 1.5 release.
Thanx god I have 9-23 build with all nice features without this one :)
...only no WB (6500/White) renders correct image. Everything else is like white-balancing clamped jpeg.
Exactly
-
Still kind of odd the order of actions would affect it to this point. Does tonemapping clamp completely ? With CameraRaw you use WB on partially compressed raw files (they're not linear) and it works fine, the dynamic range is there.
I know that with VFB+, I could use filmic+lut+wb and still retain dynamic range for post-production (lot of stops actually). So I could use another WB and exposure adjustments again in CameraRaw.
-
Only devs can explain what's going on in post in 1.5. It's really odd.
I'm sure they will make right decision and bring back old proper behaviour, otherwise Tonemapping in Corona will be anti-feature.
I refuse to believe that this is possible :)
-
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.
-
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
-
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?
-
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!
-
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...
-
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.
-
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.
-
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
-
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
-
no, it was present in daily builds before RCs
-
I have not started new projects and really looking forward to an amended version!
-
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.
-
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
-
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.
-
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
-
because we dont want for the hotfix to change behavior - it should be 100% interchangeable with the base version - for example render farms do not make difference between rendering 1.4 and 1.4 hotfix1. So we cannot name this change 1.5 hotfix 1.
-
There will be no renderfarms who wants 1.5 in this state
-
I am pleased and this decision! thanks
-
There will be no renderfarms who wants 1.5 in this state
Ondra, you made such a wonderful piece of work with all the 1.5 features and I bet there is a lot of hard work in the backstage, why ruin everything with this issue? You're only going to implement better something you guys add and is not a 100% proof production tool. People will choose this engine in the future or will continue to use it cause of the combination of simple workflow and quality!
But here, quality is left off now... I am sorry I started this post days ago but I am a professional artist and gave my support to many engines in the past and when I see something which doesn't work I need to let it know and I hope then to see efforts and fix it for the good of all the community.
-
Personally I'm pleased with solution too. But only personally.
Hotfix is the lesser evil. I don't care about my renders, now I'm on 1.5 daily, tomorrow on 1.6 daily. I won't even notice 1.5 release. I care about Corona reputation.
Release of 1.5 is already a little spoiled. All you can do now is fix it. If you let people use this while you making 1.6 then prepare for dozens of posts like this. For now it's not too late
-
because we dont want for the hotfix to change behavior - it should be 100% interchangeable with the base version - for example render farms do not make difference between rendering 1.4 and 1.4 hotfix1. So we cannot name this change 1.5 hotfix 1.
Maybe you could release it as 1.5.1 then? That way all sides should be pleased.
-
Ask any renderfarm and no one wants to install daily builds there.
1.5 release gives unpredictable renders, so they do not want to install it too. So the only choise they have is 1.4
Then they will loose all users of 1.5 release or dailies beacause lack of features and wrong shaders.
What about simple users who don't install builds? They will create dozens of negative posts till you release 1.6. They will suffer from broken tonemapping and unable to use renderfarms.
Maybe this scenario is unrealistically negative, but I'm sure that fix of this problem should be as public as it possible. Not in daily builds hidden in Dropbox.
-
Is this just a backwards compatibility issue or a new project from scratch will affected ?
I never use daily builds btw.
-
It's not just a problem of backward compatibility anymore.
In brand new scenes user can't get good tonecompressed image with low white balance. There is no way to do that in 1.5 release.
Thanx god I have 9-23 build with all nice features without this one :)
-
I see doing a hotfix (or 1.5.1 or whatever) now as the only proper solution to this problem. Since renderfarms, as previously stated, won't install daily builds for sure, what happens is that now a bunch of users have a pile of scenes rendering incorrectly. Those users will have to wait a long time (which is mostly not an option) to be able to render them properly again. In the meantime, a lot of users will create a lot of new scenes which will, when 1.6 comes out, render incorrectly all over again. I just don't see how that works for anyone.
Best to address the issue while it's still fresh and not a lot of damage done, give everyone a heads up to install the hypothetical hotfix ASAP, and get it over with.
And it would be nice, at least, if the last daily build with the old colormapping was still available in dropbox. -.-
-
Same here, please address this through a hotfix. If render farms are the only concern I'm pretty sure they can sort it out.
-
It's not just a problem of backward compatibility anymore.
In brand new scenes user can't get good tonecompressed image with low white balance. There is no way to do that in 1.5 release.
Thanx god I have 9-23 build with all nice features without this one :)
Thanks..Well then this will ruin the joy of new release. :(
-
I made a fix, PM me if you want to betatest it
-
I made a fix, PM me if you want to betatest it
Good man, thank you. We don't have time to test, here, but hope others will to help get this rolled out.
Good work!
-
I have time luckily, and if it works it'll save my @ss so consider me interested. PM sent.
-
ok, please test everything you can think of, so there is no hotfix 2 ;)
-
Now I understand why Ondra did that change in 1.5. I tried the hotfix and it works, yes, you can go back to the "old" 1.4 method and colors under 5.000K seem correct BUT...., highlights are so crap and weak while the 1.5 method alters the colors it gives superior highlight's compression.
-
Can you post examples?
-
How is that possible ? If the only change is when WB is done.
There obviously must be some good way to do it because I can adjust WhiteBalance and even tonemap (with highlight parameter) in CameraRaw/Lightroom at same time. Although I don't know what's the order of precedence.
I am gonna try VFB+ too.
-
crap, in that case it is time to remove the checkbox from devel/debug :D We definitely do not want users to use this as artistic control ;)
-
Seriously guys!!! The highlights are crap in legacy 1.5 mode! 1.5 treats highlights better but it has the color problem under 5.000K.
Ondra, you confirm?
-
This are very WIP image, don't judge me on this, take a look at the examples.
The legacy one has nice yellow tones but HC are weak and without contrast.
The 1.5 one has those bluish/cyan tones but HC are great.
-
I can't confirm that something wrong with highlights in Hotfix. My tests shows that it's nice
-
You mean 1.4 look nice???
Wait a moment, get your image, use the original HC method, not filmic, you turn on the new option (Use legacy 1.5 Color balance) and your highlights are not washed out a bit+ more blueish?
-
There should be difference in renders. You can't compare it with "broken" 1.5.
Of course if I enable "legacy 1.5" all became blue, BUT if I set WB to 6500 neutral and look to highlights then there is no visible difference between legacy and hotfix.
I think this means that difference of your images is due to white balance a bit lower that 6500. Compare neutral image and there should be no difference between legacy and hotfix.
Maybe I'm wrong. We need a 6500k test
-
I agree with you, while using 6.500K almost no differences at all. The problem appears specially under 5.000K
The images I posted are using 5.200 and you can start already see the differences.
-
it seems that in this specific scene the change in behavior just randomly produced a result that you liked better, but there should be no systematic reason why highlights in one version are better than in the other one
-
I will post some big comparison between VFB+ and Corona soon.
Corona does a lot bigger problem that kind of ties this together, it clamps. WB cannot use clamped data, it always needs dynamic range, hence why it only works on raw photography, but not jpegs.
-
Simple and stupid teapot example.
Same VFB values used.
IES 3.000K
Whitepoint 3.000K
-
In my Teapot's apartment (page 2) all is ok too.
-
Ok I did a lot of tests about which color correction features clamp the image tonal data.
LUT- does, but can be corrected. (see my other thread)
Contrast- doesn't, great !
HC- does...but only with higher values (4-5 and higher). And higher values are pretty much anything above 5. This is imho by design as tonemapper is supposed to compress tones, and once it compresses them too much, WB cannot work properly. WB needs dynamic range in highlights to work properly.
Filmic - does...but only with higher values ( 0.5 and more ). Again, by design.
Unless there is some trick/heck WB cannot be last in chain imho, because it will only work in some cases, and won't in others. WB needs to be applied at stage where image still 100perc. has dynamic range, I think this is what Adobe CameraRaw does also.
-
Building the hotfix right now
-
Thanks for your efforts Ondra.
-
and it is out
-
and it is out
Great stuff. So at this point if we load a 1.4 scene into this latest 1.5 Hotfix 1 and render it, we should see zero differences, is that right? Or is there anything to be aware of?
Cheers,
-
and it is out
Great stuff. So at this point if we load a 1.4 scene into this latest 1.5 Hotfix 1 and render it, we should see zero differences, is that right? Or is there anything to be aware of?
Cheers,
If you used contrast before, it will look different, because the new contrast replaced old one without any legacy option. New contrast is 100perc. identical to Photoshop, it doesn't darken exposure or crushed blacks (works in gamma space).
-
and it is out
Great stuff. So at this point if we load a 1.4 scene into this latest 1.5 Hotfix 1 and render it, we should see zero differences, is that right? Or is there anything to be aware of?
Cheers,
If you used contrast before, it will look different, because the new contrast replaced old one without any legacy option. New contrast is 100perc. identical to Photoshop, it doesn't darken exposure or crushed blacks (works in gamma space).
Ok thanks, good to know. That's a fairly minor thing and easy to deal with.
-
Aaaaand the hotfix is out: https://corona-renderer.com/download/
-
Champagne!
-
wubalubadubdub! missed this thread. glad theres a fix now!