Author Topic: Tonemapping Order/Behaviour  (Read 7794 times)

2023-08-09, 15:16:11
Reply #30

Juraj

  • Active Users
  • **
  • Posts: 4806
    • View Profile
    • studio website
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).
Please follow my new Instagram for latest projects, tips&tricks, short video tutorials and free models
Behance  Probably best updated portfolio of my work
lysfaere.com Please check the new stuff!

2023-08-09, 15:30:32
Reply #31

piotrus3333

  • Active Users
  • **
  • Posts: 277
    • View Profile
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.
« Last Edit: 2023-08-09, 15:40:02 by piotrus3333 »
Marcin Piotrowski
youtube

2023-08-09, 15:56:28
Reply #32

Juraj

  • Active Users
  • **
  • Posts: 4806
    • View Profile
    • studio website
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.
Please follow my new Instagram for latest projects, tips&tricks, short video tutorials and free models
Behance  Probably best updated portfolio of my work
lysfaere.com Please check the new stuff!

2023-08-09, 16:34:47
Reply #33

piotrus3333

  • Active Users
  • **
  • Posts: 277
    • View Profile
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.
Marcin Piotrowski
youtube

2023-08-09, 17:27:56
Reply #34

piotrus3333

  • Active Users
  • **
  • Posts: 277
    • View Profile
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"?
Marcin Piotrowski
youtube

2023-08-11, 13:25:40
Reply #35

maru

  • Corona Team
  • Active Users
  • ****
  • Posts: 13295
  • Marcin
    • View Profile
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)
Marcin Miodek | chaos-corona.com
3D Support Team Lead - Corona | contact us

2024-12-11, 08:33:46
Reply #36

brr

  • Active Users
  • **
  • Posts: 141
    • View Profile
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)

Hi Maru,

Do you have an ETA for this?

thx
« Last Edit: 2024-12-11, 10:02:52 by brr »

2024-12-11, 09:21:23
Reply #37

dj_buckley

  • Active Users
  • **
  • Posts: 1014
    • View Profile
Whilst we're talking about tone mapping stack behaviour - the issue with curves at the bottom of the stack still exists too https://forum.corona-renderer.com/index.php?topic=43433.msg227426#msg227426

2024-12-11, 14:08:12
Reply #38

Aram Avetisyan

  • Corona Team
  • Active Users
  • ****
  • Posts: 817
    • View Profile
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)

Hi Maru,

Do you have an ETA for this?

thx

Hi,

Marcin is off currently, here are my points about this:
  • ACES OT is something like Display/view transform in Color Management - it is applied as the last thing, to "bring" values to display/color space specific equivalents. Regarding this, we introduced a warning message with OCIO workflow if ACES OT is enabled, as it effectively applies the transformation(s) twice, possibly causing wrong results (artistic control is nevertheless allowed and welcome). What tone curve and ACES OT (and other operators) do can be better described/understood by placing a curves operator before/after an operator, and checking the histogram to see the effect of an operator. They alter the values in a specific way. 3ds Max color management view transformation, in case of OCIO workflow, is always applied after tone mapping. So
  • there is no correct/wrong behavior. There is a known/best practice on how to do tone mapping and view/color transformation, for a broader VFX industry, but not necessarilly for Corona or archviz, at least now. I have seen people using vignette right after simple exposure, and it is weird for me, but hey, if it pleases the eye, go with it
  • Operators work on the very values that are rendered. An operator changes the values, the next operator does too, and so on. I believe there is no operator in Corona which works in a specific value (low, high) range, they work on the values that are there before applying an operator. There was just the LUT related improvement, which worked considering the values were gamma-mapped, while there are LUTs which are supposed to work with linear values, and we introduced the "linear" checkbox for this. This does not mean that LUT works in HDR and e.g. contrast works in LDR
  • The important part is the linear workflow breaking or not-breaking. Simply put, this is, if you were to put all the layers of the render (lighting, relfection, refraction etc.) on top of each other and add them linearily, then optionally also gamma-correct (or view transform it), would you get exactly the same render or not. There are operators which will break this (ACES OT, Tone Curve, etc.) and these operators have this clearly stated in their tooltips. If you are not compositing using layers, you probably don't want to care about this.
Aram Avetisyan | chaos-corona.com
Chaos Corona QA Specialist | contact us

2024-12-11, 14:11:25
Reply #39

Aram Avetisyan

  • Corona Team
  • Active Users
  • ****
  • Posts: 817
    • View Profile
Whilst we're talking about tone mapping stack behaviour - the issue with curves at the bottom of the stack still exists too https://forum.corona-renderer.com/index.php?topic=43433.msg227426#msg227426

We have checked it earlier, and it seems to be expected. It was not so slow for me, but curves/histogram should process all the values, and display them, so it takes time and can be hardware/system dependent. I have suggested using some optimization (maybe less accuracy), but it is for some other time, if it is decided to improve this. So, as of now, the slow responsiveness may be expected for high resolutions and many operators for curves/histogram to process.
Aram Avetisyan | chaos-corona.com
Chaos Corona QA Specialist | contact us

2024-12-11, 14:54:00
Reply #40

pokoy

  • Active Users
  • **
  • Posts: 1953
    • View Profile
Quote
there is no correct/wrong behavior...vignette operator...

Funny you mention vignette in the same paragraph. Vignette *should* be applied before any TM, otherwise it would be more visible over HDR values than it should. A pixel with a luminance value of 4 (sorry for the wrong wording, doing it for the sake of clarity) would result for example in a value of 3.5 - still overbright, hence white in the tone mapped image.
On a tone mapped image it would work on a value of 1 and the result could be 0.75 - this wouldn't be correct.

Some operators do work differently and while we can be artistic with them, I agree, it would be nice to know which ones are designed to be HDR-aware by you. It could be that development didn't care for operators to work in HDR, in that case this is the answer - not 'the order is up to you'.

And since we're talking about operators - Corona has the worst saturation adjustment operator on this planet (maybe only matched by max built in CC node which is similarly unpredictable). Are there any plans to redesign it and provide something that will finally work for human vision?



2024-12-11, 15:15:06
Reply #41

Frood

  • Active Users
  • **
  • Posts: 1976
    • View Profile
    • Rakete GmbH
Corona has the worst saturation adjustment operator on this planet

I'm sick of repeating myself but you did that one for me, thanks :)


Good Luck



Never underestimate the power of a well placed level one spell.

2024-12-11, 15:50:56
Reply #42

dj_buckley

  • Active Users
  • **
  • Posts: 1014
    • View Profile
Whilst we're talking about tone mapping stack behaviour - the issue with curves at the bottom of the stack still exists too https://forum.corona-renderer.com/index.php?topic=43433.msg227426#msg227426

We have checked it earlier, and it seems to be expected. It was not so slow for me, but curves/histogram should process all the values, and display them, so it takes time and can be hardware/system dependent. I have suggested using some optimization (maybe less accuracy), but it is for some other time, if it is decided to improve this. So, as of now, the slow responsiveness may be expected for high resolutions and many operators for curves/histogram to process.

Come on, I'm working on a multi thousand pound piece of hardware with the latest software - I can work on a 100+ layer 6k PSB file and get instant results from a Curve Adjustment layer, or a 50+ node composition in Fusion and get instant results from my histogram.  But it's expected behaviour in Corona because of a couple of tone mapping operators?

2024-12-12, 17:30:39
Reply #43

Aram Avetisyan

  • Corona Team
  • Active Users
  • ****
  • Posts: 817
    • View Profile
Quote
there is no correct/wrong behavior...vignette operator...

Funny you mention vignette in the same paragraph. Vignette *should* be applied before any TM, otherwise it would be more visible over HDR values than it should. A pixel with a luminance value of 4 (sorry for the wrong wording, doing it for the sake of clarity) would result for example in a value of 3.5 - still overbright, hence white in the tone mapped image.
On a tone mapped image it would work on a value of 1 and the result could be 0.75 - this wouldn't be correct.

Some operators do work differently and while we can be artistic with them, I agree, it would be nice to know which ones are designed to be HDR-aware by you. It could be that development didn't care for operators to work in HDR, in that case this is the answer - not 'the order is up to you'.

And since we're talking about operators - Corona has the worst saturation adjustment operator on this planet (maybe only matched by max built in CC node which is similarly unpredictable). Are there any plans to redesign it and provide something that will finally work for human vision?

As already mentioned - operators work on the values before them. Be it HDR (correct term - linear) or LDR (non linear) values.

Quote
Vignette *should* be applied before any TM
...value of 1 and the result could be 0.75 - this wouldn't be correct.

what if you want both? And most of the time the effect you are looking for is exactly the "incorrect" one, isn't it?

Again, there are no HDR or LDR specific operators, but e.g. when placing a tone curve operator before ACES OT (or any operator which breaks linearity), it will have the full range of values to work with. While if places after ACES OT (which s-curve-corrects the values) it will have a limited range. But it will still do its thing, on the new values, and there is absolutely no necessity to tell or encourage to use Tone curve (or any other operator) before some other. We believe it is best to educate/show with examples that this is about linearity and how operators react to the values.

For the saturation, I guess you want more control for shadows, darks and lights, right? Because anything photoshop like (implementing color range, lightness, hue etc. ) will most probably not be there. The feature request portal  is always available to cast a request and see how many users want it or to discuss and see what others think of it.
Aram Avetisyan | chaos-corona.com
Chaos Corona QA Specialist | contact us

2024-12-17, 13:17:31
Reply #44

Juraj

  • Active Users
  • **
  • Posts: 4806
    • View Profile
    • studio website
No, I am pretty sure he just wants saturation to work like saturation does everywhere else :- ) Just compare what saturation levels do in Photoshop, Lightroom, iPhone editor, etc.. etc. Corona Saturation causes nuclear colors the moment the value is at "0.02" (which I presume would be 100perc. more saturation in some other apps..)

There is also Vibrance, which is saturation on scale (i.e it saturates primarily low-saturated tones to avoid over-saturating the ones which are already close to peak).

HDR vs SDR(LDL) is something different than Linear/Non-linear. The first refers to values outside of (0-1) values, the second if value is linear or on (gamma 2.2 for example) curve.
The majority of operators don't actually read the previous data correctly, they either clamp them back to (0-1) or ignore values outside of that range, I can't know how it works internally, but I can clearly see the result. Ondra suggested once labeling them into groups.

But that discussion went nowhere already 5 years ago..

But the Saturation should be easy fix. The current one is completely bonkers.
Please follow my new Instagram for latest projects, tips&tricks, short video tutorials and free models
Behance  Probably best updated portfolio of my work
lysfaere.com Please check the new stuff!