Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] General Discussion => Topic started by: lolec on 2018-10-30, 05:28:25
-
Hello,
I know the answer to this question is already in the forum, probably in dubcat's hideout or something... but the subject is far too technical for me.
So I was watching this video
and wanted to try in corona. I immediately recognized the issue as something I've glanced on the forums but have never been willing to fully understand.
But I imagine, there must be others like me, that just would like to know a simple way (if it exists) to avoid or overcome this issue.
I tested with Fstorm and it seems to handle it better.
I know this is related to Linear workflow, ACES, sRGB etc... I'm not looking for the complicated answer. I just want the best possible render with the least possible tweaking, preferably straight out of the render.
Thanks :)
-
short answer: straight of the renderer, you can't.
The only way to achieve this with corona, for now, is to save your render in 16 or 32 bit exr and comp it in post.
-
Does that "for now" means a change is planned?
-
Or you can use some LUT.
-
I used Kim Amlan... graphic2 lut, which is my favorite. Which one do you recommend ?
-
What RGB values are you using for that light? If it's 255/0/0, it may already help to use 254/1/1 instead if that's what you're using.
-
I tried with 255 7 1, I get the yellow highlights on objects and white blown light. Closer, but fstorm still looks better.
Can anyone tell me if this is a "problem" on Coronas side, or if this is by design (e.g. this output is better for compositing) ?
And if it is a problem, if there is a solution in the works and what is the solution?
In my day to day, I've never encountered this scenario, and I don't really need this to be fixed. Just curious that maybe this has to do with why Fstorm renders usually look more photographic ?
Oh and BTW, thanks for your answers guys :) I really appreciate you taking the time to provide clear and concise answers instead of a lecture on why I SHOULD be an expert in X or Y to use corona.
-
In for answers.
From what I've read from Dubcats thread this is tied into either the tonemapping algorithm in Corona or something to do with the internal colour space (or both).
And yes FStorm is the holy grail as far as DSLR like tonemapping and render behavior.
-
Does that "for now" means a change is planned?
Tonemapping will be reworked but we don't know what devs have in mind.
Can anyone tell me if this is a "problem" on Coronas side, or if this is by design (e.g. this output is better for compositing) ?
And if it is a problem, if there is a solution in the works and what is the solution?
We can't see that as an issue as it is a common practice to display renders with the standard sRGB display transform. It just feels odd nowadays. HDR displays are all over the place now and we're not even able to preview our renders with an output adapted to these devices. All we need to solve that is OCIO support.
The only solution you have is to use either Fstorm or Vray if you want to benefit from the ACES tonemapping curve straight of the renderer. If you want to stick to Corona, as I've said before, you'll need to output linear RAW render and comp it in post with Fusion, Nuke, Nucoda, Natron or any other post-production software that support OCIO.
-
There is a "Reworking tone mapping (DSLR-style tonemapping)" item here: https://forum.corona-renderer.com/index.php?topic=96.0
You can vote for it, if you are interested in this feature.
Simple explanation of what is happening here:
-In Corona you specify color values for your light (e.g. R255 G0 B0) means red. The question is how we interpret those numbers. Should it get "more red" as the exposure increases? (because R is getting higher than 255) Or should it get "more white"? Currently it is getting more red, and that's expected.
-In real life light is a bit more complex phenomenon, and what reaches your camera sensor is not just R255 G0 B0, and that's why the result is white instead of red.
We can either change the way Corona interprets light internally (so high red values would mean white pixels), or somehow "fake" it, for example using LUTs. Right now you can use the built-in Kim Amland LUTs, which are based on real life cameras, and you will see that the values with high red values will turn white/pink.
-
We can either change the way Corona interprets light internally (so high red values would mean white pixels), or somehow "fake" it, for example using LUTs.
Maru, I have to admit that this is a bit scary. The aforementioned phenomenon is purely related to the transition from scene referred data to display referred data, as discussed in many other posts. Corona is computing light the right way already so why would you change scene referred behavior? I'm not criticizing anything here, I would just like to understand. Maybe I misunderstood what you said tho, but I'm a bit concerned there. Also, LUTs won't resolve anything here.
-
Sorry if my message was clear, or sounded like something nonsense. :)
What I basically meant was "we will look into possible ways how we could improve this".
We definitely won't be breaking the way Corona is computing light.
-
"We definitely won't be breaking the way Corona is computing light."
Good because in my opinion, Corona has the best lighting of all the renders :)
-
Now available through our ACES OT operator in the new tone mapping (which is also enabled by default in V9 daily builds).