Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] Bug Reporting => Topic started by: dj_buckley on 2023-07-27, 15:50:31
-
Hi guys
Getting some funky results with various tonemapping combinations.
The effect of the Tone Curve operator appears to inverse depending on whether it's above or below the ACES OT Operator.
We've been advised to keep ACES OT at the bottom, so let's assume Tone Curve being above ACES OT is the correct way to go.
However, when I have it in that order, the settings appear to do the reverse of what I'd expect. i.e. changing Highlights to 1.0 makes the highlights duller. Changing them to -1.0 makes them brighter.
It's also have a strange effect on the bright spots in the HDRI. The bright spots on the HDRI appear to adjust inversely to the bright walls.
So when I adjust the highlights to -1.0 the walls get bright, but the HDRI bright spots get dull. When I adjust the highlights to 1.0, the walls get dull but the HDRI bright spots get brighter.
In the attachment, the very bottom image is the one that appears to be working as I'd expect it to, but that has the tone curve placed below ACES OT.
Confused .....
-
Hi,
I am unable to reproduce the 1st 2 behavior you have shown in your Image in which the sky and walls are getting affected inversely. I was able to reproduce 3rd and 4th. However, the correct way to use tone mapping is to use it above Aces OT. As per my investigation, when tone mapping was above aces OT and I set the highlight value to -1 then both Sky and bright wall highlights went dull and when I set the highlight value to 1, they were both boosted.
I have checked this with default settings, Corona Sun and sky, and using a day HDRI from Cosmos. In both ways, I got the same behavior.
-
Hmm I'm wondering now then if it's related to the Curves bug I posted about. I'm pretty sure this scene originally had Curves in the Tonemapping stack which I've since deleted and assumed the stack was working fine again https://forum.corona-renderer.com/index.php?topic=40316.0
Could you try adding Curves in various combinations, doing some processes, renders, deleting curves and see if your Tonemapping stack still works as expected.
Maybe repeate the processes described in that thread, save a scene, continue working in it etc etc
-
However, the correct way to use tone mapping is to use it above Aces OT.
ACES OT is tone mapping. No reason to do it twice.
-
However, the correct way to use tone mapping is to use it above Aces OT.
ACES OT is tone mapping. No reason to do it twice.
Each to their own. Personally I find ACES OT too aggressive on the highlights. So I like to tweak to taste with the Tone Curve. Creative license and all ....
-
Tone Curve in Corona isn't really tonemapper, it's mostly parametric Curve and somehow weirdly behaving, I played with it a bit and it's just odd. Right now the whole stack is mostly a mishmash of modifiers working either in SDR or HDR with no designation. I personally avoid using Tone Curve completely. Or most modifiers in fact.
The reason while stacks in Lightroom/ACR or Unreal 5 work so well is because everything is hardcoded to work in intended space and order of operations. Tone Curve in Lightroom is automatically working in linear space when Raw File is opened, and just like regular curve when SDR file like jpeg is opened. Result is always what you expect there.
And while ACES OT in full-scale ACES Workflow is meant as output at the end of stack, the workflow requires everything to work that way (in HDR space). Whereas in Corona, ACES OT is just singular tonemapper modifier to be used however you want. And most of the combinations with other modifiers just don't work...
-
Either way, I'm just trying to find out why, in that specific instance, it wasn't working as 'sold'. It wasn't intended to start a debate about tonemapping :)
-
Yeah sorry for the unintended tangent, not sure why I even wrote all that lol.
I actually wanted to write but somehow got lost, that imho the behavior is working as intended, it's just visually it is "wrong". It can't account for what ACES OT will do afterwards, and ACES OT really doesn't work with majority of current modifiers before it.
I had mentioned this quite a lot in chat with devs but correcting it would probably require rebuilding this pipeline without the legacy behavior and compatibility.
-
It's all good. I strongly think the other thread I linked to has something to do with it. Especially if Avi wasn't able to replicate it.
-
if highlights need to be adjusted do that with simple Curves operator before ACES OT.
Tone Curve op seems to be intended to be applied after tone mapping.
comparison of Tone Curve highlights -1 with ACES OT within 0-1 range:
-
Tone Curve op seems to be intended to be applied after tone mapping.
This would correlate with the example I felt was working 'as intended', but as I say, I questioned it because I've seen the Corona devs mention multiple times in these forums that ACES OT should come last.
-
and my bad - in my first post I confused Tone Curve with Filmic which does exactly what is on the tin:
-
Tone Curve op seems to be intended to be applied after tone mapping.
This would correlate with the example I felt was working 'as intended', but as I say, I questioned it because I've seen the Corona devs mention multiple times in these forums that ACES OT should come last.
not necessarily as long as you keep in mind you are adjusting already adjusted colors. and last element in the stack is still before final view transform applied by CIE and not accessible through UI.
-
Yeah Tone Curve here is just name for parametric control of normal Curves, it's just what Lightroom (and few other Raw editors) calls it.
The devs should perhaps just added those controls to normal Curves modifier and it would at least visually show what is it doing each time.
-
However, the correct way to use tone mapping is to use it above Aces OT.
ACES OT is tone mapping. No reason to do it twice.
Sorry, I made a typo mistake, I meant Tone Curve not Mapping.
and @dj_buckley, I tried the repro steps as you posted but I still cannot repro the same behaviour as you are pointing out. Can you perhaps share your file with me and some repro steps so I can try that and see if that is happening with me.
-
Hopefully this is an easy way to explain what is going on and hopefully I got it right. :)
first strip is RGB 0 to 1
second one is 0 to 100
third one is 0 to 500 000
If we only consider the ACES OT operator:
1) When it's disabled, you get a full HDR image. RGB values can exceed 1 and go super high.
2) When it's enabled, nothing can be brighter than RGB 1
If you move the Tone Curve (or pretty much any) operator above or below the ACES OT operator, you are basically applying the same operator to a different image.
-
Ok we get that bit, but which is the 'correct' way. Everything I read says keep ACES OT as the bottom of the stack. But in that particular scene my Tone Curve operator was behaving in complete opposite ways depending on whether it was above or below. Surely that's not right despite them being different images.
Are all of the operators designed to be used above ACES OT in the stack?
I'll reproduce it and send the scene.
Either way I strongly suspect it was the dodgy curves operator that screwed that scene up
-
I've just created a support ticket with a scene file attached.
-
And here's a screen recording
-
to quickly visualise what operators do to colours use 32 bit gradient (0 - 2 float is probably enough to see the important parts) processed with CIE and displace modifier in 3ds max on a plane:
-
Ok we get that bit, but which is the 'correct' way. Everything I read says keep ACES OT as the bottom of the stack. But in that particular scene my Tone Curve operator was behaving in complete opposite ways depending on whether it was above or below. Surely that's not right despite them being different images.
Are all of the operators designed to be used above ACES OT in the stack?
I'll reproduce it and send the scene.
Either way I strongly suspect it was the dodgy curves operator that screwed that scene up
If you put any operator ABOVE Aces OT - you are applying it to this image (i.e. a huge range of RGB values) - https://forum.corona-renderer.com/index.php?action=dlattach;topic=40616.0;attach=186553;image
If you put any operator BELOW Aces OT - you are applying it to this image (i.e. a "flat" image clamped to 0-1 range only) - https://forum.corona-renderer.com/index.php?action=dlattach;topic=40616.0;attach=186555;image
So it is expected that you will get completely different results.
You can use whatever order you prefer, but I would say that putting ACES OT as the last one in the stack is more correct. This way you make some adjustments to your full high dynamic range image, and clamp it to 0-1 range as the last step.
-
Marcin - did you watch the video?
I'm not questioning what you're saying at all. I fully appreciate and understand that. But I would have thought that increasing the highlights value in the Tone Curve operator to a positive number would make the highlights brighter regardless of whether it was on a clamped or unclamped image.
And it's exactly when the tone curve operator is above ACES OT that I'm having issues. As you can see in the screen recording and the screenshots in the very first post. When I have the Tone Curve above ACES OT, using minus value increases the highlights and using positive values decreases the highlights.
Surely that isn't right at a fundamental common sense level of understanding.
It's basically doing the opposite of what you're telling me it should be doing. Even the tooltip in the VFB verifies this. Postive values make highlights brighter etc
It doesn't behave this way if I place it below ACES OT, it behaves as expected, albeit on a now clamped image.
-
Marcin - did you watch the video?
I'm not questioning what you're saying at all. I fully appreciate and understand that. But I would have thought that increasing the highlights value in the Tone Curve operator to a positive number would make the highlights brighter regardless of whether it was on a clamped or unclamped image.
And it's exactly when the tone curve operator is above ACES OT that I'm having issues. As you can see in the screen recording and the screenshots in the very first post. When I have the Tone Curve above ACES OT, using minus value increases the highlights and using positive values decreases the highlights.
Surely that isn't right at a fundamental common sense level of understanding.
It's basically doing the opposite of what you're telling me it should be doing. Even the tooltip in the VFB verifies this. Postive values make highlights brighter etc
It doesn't behave this way if I place it below ACES OT, it behaves as expected, albeit on a now clamped image.
no, I did not watched the video as I checked and showed with a graph few post ago what Tone Curve exactly does. ploted curve tells me more.
Tone Curve is only usable on tone mapped image: when it adjusts highlights it does so only to a range of ~0.6 - 1.0 float with a pivot placed at 1,1 (x,y). Pivot at this point means that suppressing the highlights to -1 with Highlights spinner in Tone Curve (at ~0.8) results in values above 1.0 float to increase substantially. Hence your issues with using Tone Curve above ACES OT.
-
It doesn't behave this way if I place it below ACES OT, it behaves as expected, albeit on a now clamped image.
on a tone mapped image, not clamped image. clamping would be cutting or truncating values.
-
Marcin - did you watch the video?
I'm not questioning what you're saying at all. I fully appreciate and understand that. But I would have thought that increasing the highlights value in the Tone Curve operator to a positive number would make the highlights brighter regardless of whether it was on a clamped or unclamped image.
And it's exactly when the tone curve operator is above ACES OT that I'm having issues. As you can see in the screen recording and the screenshots in the very first post. When I have the Tone Curve above ACES OT, using minus value increases the highlights and using positive values decreases the highlights.
Surely that isn't right at a fundamental common sense level of understanding.
It's basically doing the opposite of what you're telling me it should be doing. Even the tooltip in the VFB verifies this. Postive values make highlights brighter etc
It doesn't behave this way if I place it below ACES OT, it behaves as expected, albeit on a now clamped image.
no, I did not watched the video as I checked and showed with a graph few post ago what Tone Curve exactly does. ploted curve tells me more.
Tone Curve is only usable on tone mapped image: when it adjusts highlights it does so only to a range of ~0.6 - 1.0 float with a pivot placed at 1,1 (x,y). Pivot at this point means that suppressing the highlights to -1 with Highlights spinner in Tone Curve (at ~0.8) results in values above 1.0 float to increase substantially. Hence your issues with using Tone Curve above ACES OT.
I meant Maru (also called Marcin)
-
heh.
anyway, does it clear things out?
-
Sure, you're effectively confirming what I'm saying/experiencing. But Maru is effectively saying the opposite.
You're saying Tone Curve is only usable on a tone mapped image. So below ACES OT in the stack.
Maru has said the most correct way would be to use it above ACES OT, so before tonemapping.
The tooltip just confuses things further by not specifiying either way and the tooltip basically says positive values will make highlights brighter etc - but as I've found out and you've proved, it only works that way if placed below the ACES OT in the stack.
So this is ultimately why I asked for confirmation. We've got the people who make the software saying one thing, and the users saying another.
Also for what it's worth, I do expect different results from the Tone Curve dependant on whether it's above or below ACES OT. I've understood that from day one. My issue wasn't necessarily with suppressing highlights either. In fact the exact opposite, I want to bring them back. Increase them. But you can't increase the highlights with tone curve operator when it's placed above ACES OT, it does the opposite. It decreases them. It completely flattens them. When placed above ACES OT in the stack. Positive highlight numbers in the tone curve operator progressively suppresses the highlights.
Also if what I'm experiencing is correct, and what you're saying is correct, then the tooltip should explicitly state that it only works as described when placed below ACES OT in the stack.
-
I think we are dealing with a very simple issue here, but it's tricky to explain. I will do my best to get a proper, easy to understand answer here.
Sorry for the confusion and it seems that it would be also great to update our help guides once we have the final results!
-
From my personal experience, a few operators just don't work well when used before ACES operator (or Reinhard/filmic tone mapping prior to availability of ACES):
- Tone Curve - results are not consistent (probably due to the 'response curve' of ACES acting differently on different brightness levels)
- Contrast - same
- LUT - same
- Saturation - this one has been wonky since day 1, it's way too aggressive but seems to behave slightly better after ACES
The only ones that I use before ACES are the obvious ones - Exposure, White Balance, Gree/Magenta Tint. Sometimes, I'll use Highlight Compression before ACES to increase/reduce highlights (this one is meant to work on HDR input after all).
I don't follow the 'Keep ACES always the last in the chain' rule because it just doesn't look good for some operators. Rules exist to be broken :D Also, I'm pretty sure some are definitely NOT meant to be used before ACES, like LUT.
-
I think we are dealing with a very simple issue here, but it's tricky to explain. I will do my best to get a proper, easy to understand answer here.
Sorry for the confusion and it seems that it would be also great to update our help guides once we have the final results!
Correct, it's very simple. You said the most correct way to use Tone Curve is above ACES. The tooltip for highlights in the tone curve operator states 'positive values enhance them, negative values suppress them' - but when I place Tone Curve above ACES OT and use a positive value for highlights it suppresses them, if I use a negative value it enhances them. It's that simple.
The video I posted clearly demonstrates this.
-
Maybe labelling operators as "HDR" (to be used before any Tonemapper in stack) and "SDR" (to be used after Tonemapper) would be good indicator where to properly use modifiers.
Of course, for artistic freedom, any combination can be done.
Ondra effectively suggested the same, but he wanted to label SDR as sRGB which would be incorrect when full color management is implemented.
ACES Tonemapper as last step of color grading is only done in softwares/pipelines where all operators are fully HDR, like in Unreal 5 (with exception of LUT of course).
-
why label Tone Curve SDR if it does indeed handle hdr input and outputs also an hdr image?
grading within aces system is almost always done in one of the aces log spaces, no need for hdr tools.
edit: and tone mapper is indeed the last operation before pixels go to screen.
-
You nit-pick part of answers out of context, add words no one said, and I am just confused what are you trying to say then really.
Then you also write it in such weird condescending way that is meant to convey authority over the topic?
Input/Output wouldn't be what denotes the operator, the operation mode would. Even LUT in Corona uses hack to output partial HDR data (by extending highlights, trick that Ondra copied from VFB+ plugin after many requests, as it was very handy feature).
We don't have any ACES system, we have ACES Tonemapper, one element taken out due to popular request, operating in HDR space, not LOG. So what do you mean by no need for HDR tools? We're not talking about any movie pipeline, we're talking Corona Framebuffer.
Also framebuffer in Corona/Vray isn't a color grading operation only, it's also compositor and since it was built based on user requests, now offers hybrid approach that slowly encroaches towards "PhotoshopLite". So Tonemapper isn't last in order by any requirement.
-
ACES Tonemapper as last step of color grading is only done in softwares/pipelines where all operators are fully HDR, like in Unreal 5 (with exception of LUT of course).
I'm just not ok with misinformation.
If I'm coming across as condescending - apologies, it's not intentional.
-
ACES Tonemapper as last step of color grading is only done in softwares/pipelines where all operators are fully HDR, like in Unreal 5 (with exception of LUT of course).
So what do you mean by no need for HDR tools? We're not talking about any movie pipeline, we're talking Corona Framebuffer.
yes, I'm talking about frame buffer of Corona.
no need for "HDR tools": you're claiming that aces tone mapper is last operation only where all operators are "fully hdr". there is no usable software manipulating colours that does that. its not very convinient to colour correct in hdr and colour grading is near impossible. who does that? all that is conveniently done in ldr, so it's possible to see the image, see the colour curves in a display specific range (or whatever other tool). addition and multiplication is all you need from "hdr" operators. everything else can operate within displays 0-1 range.
one thing I would like to clarify, if possible:
Input/Output wouldn't be what denotes the operator, the operation mode would.
what do you mean by operation mode"?
-
We looked into this and indeed the way it works is at least "counter-intuitive". This is now logged for our devs to review and here are the further steps that we are planning to take:
- explain the current behavior
- share what the correct order is for these and other operators
- feature request: mark which operators work in low and high dynamic range
(Internal ID=1177158641)