New Sigmoid Scene to Display mapping

Originally, but Aurélien put a lot of work into making what it is today. @Carmelo_DrRaw has his versions in PhotoFlow, which are very different. And I think we talked about others as well on the forum.

Ya that is sort of what I meant. A comment above said that there were no curves for HDR but certainly I think Blender can handle HDR data??

I’ll have a look!

I think I used a too sloppy wording. As an EOTF for SDR does not specify absolute brightnesses but ‘only’ relative brightnesses, the camera basecurves that @jandren is talking about as a reference all include at least some creative decisions of how scene-linear is transferred to stored codevalues. For HDR this is a bit different because codevalues stored ‘should’ be actual brightnesses the viewer will enjoy. This pushes, or should push, the creative decisions of how something looks into the realm of ‘modified scene-linear’ and away from the final ‘HDR-basecurve’.

HDR:
scene-linear → creatively modified scene-linear → HDR-OETF → stored codevalues → HDR-EOTF(manufacturer decides how 4000nits is rendered on 1000nits display, but 800nits is likely 800nits)-> display brightness
SDR:
scene-linear → creatively modified scene-linear → SDR-OETF (basecurve, can contain creative tonemapping decisions) → stored codevalues → SDR-EOTF (overall brightness & gamma is somewhat up to display manufacturer) → display brightness

So there is no real equivalent to a basecurve in an HDR workflow BUT of course people could implement one in order to achieve a ‘look’ by slapping on a custom HDR-OETF over their scene-linear data. :man_shrugging:

Agreed!

No, they are the boundaries of the dynamic range.

That’s where, before talking film curves, understanding film could prove itself useful.

Black relative exposure is Dmax. White relative exposure is Dmin. Contrast is the slope of the film sensitometry curve, aka the gamma of the film. Hardness is the slope of the paper sensitometry curve, aka the gamma or hardness of the paper. The latitude is the area of the dynamic range where the sensitivity is roughly linear. What we do in filmic is modeling a virtual print of a virtual positive we create on a virtual paper we define.

See https://www.kodak.com/uploadedfiles/motion/US_plugins_acrobat_en_motion_education_sensitometry_workbook.pdf


Log-logistic is great as long as you don’t mind your mid-tones contrast imposing the rate of transition in toe and shoulder as well.

Filmic lets you manage the 3 separately to define more than a blind curve : it defines a virtual film emulsion. Is it good, is it bad ? I don’t care, we know how to handle that, it’s a known territory.

So yeah it’s more parameters, but it’s also more control… Also the spline has an option to use cubic or quadric toe and shoulder such that you can control precisely how fast you converge to white and black. And if you set the latitude to 0, then you remove the linear central part to keep only the quadric/cubic toe and shoulder with slope continuity.

If your grip is with how filmic deals internally with parameter covariance… That can be fixed. We ultimately just need to put 4 nodes in a log2/log_something space, ensure we intercept middle grey, draw a 3 parts S curve with a linear middle part to connect those dots, and bring back everything to linear. Everything in-between is to help users, if it goes in the way, it can be changed.

But removing all parameters for a solution where everything is tied together, pull one thread and the whole sweater comes with it, I don’t call that progress. Perhaps it will appeal to the 2-clicks-magic crowd. But you don’t create a virtual emulsion + print anymore, that’s something else. And at very least, I want to be able to control the transition rate of shadows and highlights aside from the midtones contrast, thank you very much. I have no doubt you can come with a nicer and more elegant solution if you ditch that ability, but that’s kind of important to shape the curve.

And, yes… like any spline, not all parameters give a correct curve. Oscillations happen, overshoot and undershoot too, over-constraining a spline is never a good idea. Take any tone curve, go wild with it, and you will make it unstable just as well. But we are still using them because, so far, it’s the only way to interpolate smoothly a collection of sparse points.

Maybe we could add extra checks, for example ensuring the second order derivative of shoulder and toe is never == 0 and do something about it, but what ?

8 Likes

Thanks for the link @anon41087856! I have read some other papers on film emulsion but that one was an easier read. So gamma = slope of the negative film * slope of the paper?

I’m sure the filmic module is correct, my points above were more intended at pointing out that the actual room for control is smaller than it seems. Most parameters are restricted to a very narrow space to make that the curve works well. The gamma/hardness value for example is constrained by the other settings and can not be picked freely or based on real products. Picking a hardness value based on a specific negative and paper combination would constrain the other parameters instead. Nothing wrong with such a technical approach but I’m sure not everyone likes that kind of workflow.

That said, I’m just looking at the problem of tone mapping from a slightly different perspective. Noting what mathematical properties it has to fulfill and what other commonly used tone curves look like. It is not like I want to replace or change the filmic module, I’m just looking for other ways to parameterize such a curve. And I’m not looking to please “the 2-clicks-magic crowd”, those dudes would use a LUT and I also hate that kind of workflow. No, I have in mind a parameterization with orthogonal settings, simple as that. One parameter worked surprisingly well, and that is what my original post introduced, but I do see the need for at least one more degree of freedom so I intend to explore that need.

@priort I think the Blender Filmic output is sRGB only. Anyone currently targeting an HDR display device with Blender content probably just exports as linear ACES and imports that into some other grading software. Might be possible to define a custom setup with OCIO but that is not included per default as far as I know. The Filmic Log output is as far as I can tell just another interchange format and not a delivery format.

@PhotoPhysicsGuy

Yes, without affecting too much of the prior chosen curve. ‘highlight punchyness’ or ‘highlight detail’ or highlight recovery’ however you want to call it. BUT let me be clear that I would be open to discussing whether this must be part of display mapping or not

I see the need as well and the mathematical flexibility to solve it. So I definitely think it should be part of a good tone curve parameterization. And thanks for the clarification! Good to know that we are thinking about the same limitation.

So there is no real equivalent to a basecurve in an HDR workflow

I’m a bit confused by this statement. There is a “base curve”, at least as far as I can tell from extracting the values from the ACES HLG 1000 nits synthetic sample image. Haven’t checked the PQ/ST 2084 version but I expect similar results. And why wouldn’t there be? Even an HDR screen can’t display an infinite amount of light intensity so there needs to be some sort of tone mapping to not clip out of bounds values but rather letting them converge to the maximum display brightness. Both map infinite to finite, just a different finite range! Working on adding this to the tone explorer.

@afre Haven’t used PhotoFlow myself, how is the implementation there?
And about standardization, oh yes! It’s all about screens and what they accept in the end! Its especially hard to discuss this topic without access to such a display, how on earth should we be able to test it in that case? The best I can do is fulfill the mathematics and imitate established methods.

1 Like

Not really, each medium (film and paper) has its own gamma, which is the slope in log/log space, aka the exponent in linear space. So the film printing process as a whole is log/log tone mapping overall.

The paper hardness, in darkroom, was chosen based on the contrast of the film, to compensate it. If the film was already very contrasted (large Dmin - Dmax), the lab techs would chose a low paper grade. And the other way around. So it’s consistent with what it represents, and it has never been an orthogonal setting, more like an adjustment variable.

I’m all for that, but outside of splines, which are very generic with the oscillatory drawbacks we have seen, you might end up needing 3 or more different kinds of sigmoids to control the shape, which may not, at the end, solve the initial problem of degrees of freedom reduction.

It’s not much about color spaces, rather than… OCIO ships LUTs, that is someone (Troy Sobotka) pre-computed the view-transform with sane dynamic range parameters times a couple of more/less contrasted variants and put that into a static file. darktable filmic’s re-uses the same logic but with an interactive UI, which gives plenty of options for users to harm themselves.

1 Like

Quite a few modules use filmic like theory in PhotoFlow, each of them using a different algorithm, some developed by @Carmelo_DrRaw himself, others adapted from others . If you want

then use the OCIO filmic module. I don’t keep track of them because I only use PF for basic functions like demosaicing.

1 Like

Its probably been mentioned somwhere before but this (Filmic Tonemapping with Piecewise Power Curves) is another possible approach. If I remember correctly, at least one version of the tone mapping module in Photoflow was developed from this.

One thing that wasn’t immediately obvious (to me at least) is that Film sensitivity curves are plotted on a log-log scale (density (log reflectance/transmittance) vs. exposure (log light)). So the straight line bit around the mid-tones corresponds to a power function in the linear light domain.

2 Likes

Added the Scene to linear sRGB and HLG display values extracted from the ACES synthetic reference image: https://share.streamlit.io/jandren/tone-curve-explorer

The CSV contains the raw values cropped from the .exr and tiff pictures so you can check the source and double-check that I did things correctly. I added one modification, I aligned them with the others middle grey, i.e. changed the scene exposure such that all produce 0.1845 at 0.1845. The shape and it makes it easier to compare them with the others.

The earliest use of the word ‘filmic’ in regard to what we’re doing here was by this fellow:

http://duikerresearch.com/tag/filmic/

At this link, visit the John Hable posts on the topic, and you’ll find equations and other useful stuff.

2 Likes

Maybe my point is a bit philosophical, but codvalue=display-brightness is a more rigid concept than ‘gamma’ in sRGB.
See in BT.2390 Section 3, 4 and 5. Specifically the differences in figures 10 and 12 and how the artistic decision is pushed to earlier in the pipeline, before encoding linear light to codevalues.

I think madshi started out using hable tonemapping for his HDR to SDR work in madVR aswell…currently searching this thread for it: madVR - Doom9

EDIT: it seems that madshi is using a curve from the above BT.2390 paper for mapping from HDR to SDR. Section 5.4.1 describes such curve. A cubic hermite-spline that looks rather monotonic in figure 20. In their example, the rolloff point is a fixed value below peak display brightness. Don’t know how this reacts if one plays with this rolloff point. Upon first glance comparison with https://en.wikipedia.org/wiki/Cubic_Hermite_spline they seem to have dropped the h_[11] basis function.

EDIT2: The cubic-hermite-spline out of edit1 is implemented for example in DisplayCAL and in VLC and at some point in Colour-Science for Python. Of course, adoption of a certain spline is not saying anything about how adjustable a spline is. But my wild guess is that you can’t throw around splines for various applications if the spline is not well behaved.

2 Likes

Update with curve from Blenders Filmic look. The source data directly dumped into a csv in the repository so that you can see what I’m doing with it. I think something is wrong for the x-axis allocation but the overall shape should be correct so worth posting. Two notable things stand out for me: one the curve is again bell shaped, two low contrast yields the same kind of exponential decay shape as the log logistic curve returns. Also note how it is possible to see how Blenders filmic curve is made out of three segments and that there is a slight slope mismatch between them!

@PhotoPhysicsGuy, about the gamma, hdr code value etc. I had liked to keep all of that out of this. I’m imagining the output of scene to display mapping to be in linear (relative or absolute) floating point data. Any modifications done for good quantization such as sRGB gamma, HLG mapping or PQ mapping would be done as a separate step afterward. About different versions of splines, my current idea is to rather go in the direction of @paulmiller’s link with piece wise power functions. Thanks for a really good link!

1 Like

Prudent. Keep in mind your display/output profile also has a tone curve, usually “gamma-like”… so, what you’re feeding to it from filmic/whatever is getting further tone-munged.

I recommend everyone to check out the results!

What I see basically: With minor deviations, the log-logistic curve can reproduce Troy Sobotka’s implementation of filmic (which doesn’t over or undershoot) for all of his seven different contrast settings…with the addition of being smooth in the first derivative…and covering all values in between. On top of this, skewness as a parameter isn’t even implemented for log-logistic.

While I do understand the need for ‘more parameters’, especially if one wants to emulate the complex process of color-negative film and positive-printing-paper, the fact that the log-logistic curve is SO well behaved AND emulates very different scene-to-display mappings is not something to dismiss easily.
(And no, this is not about ‘one-click’ solutions, but maybe more an elegant choice of a curve/parameter for perceived contrast)

Sure, I tried to adress points that Aurelièn brought up. After reading the BT.2390 whitepaper I think there is a good solution, that could also be part of a different module.

You’re welcome. Looking forward for the results!

1 Like

You know Troy used cubic splines ? Also I think his hardness was always 2.4. So take current filmic module, set latitude = 0 and the highlights/shadow strength to “soft” (aka 3rd order polynomials), and done. The piece-wise polynomials have a slope continuity constraint where they meet, so that’s it.

The beauty of designing a general framework is it can always be specialized later. The other way around doesn’t work.

3 Likes

I speculated this.
Good to know.
Sure, but it’s super elegant and quite curious that log-logistic does not have discontinuities while reproducing artefact free all the curves, no? If it’s not useful for the filmic module, I can see reasons why! At the same time: this is not yet-another-basecurve.

If by ‘general’ you mean ‘low-complexity’ and by specialized you mean ‘more complex only when needed’, I agree (Sometimes called Occam’s razor).

1 Like

Here’s an idea I came up inspired by the logistic curve in this thread.
Creating a curve with a knee and shoulder using two logisitic functions.
I basically use two scaled logistic curves. The scaling factor L scales both the functions and is the point where the two curves meet. Furthermore you can change the parameter c (let’s call this contrast) which set the steepness of the middle part.

[Sorry found some typo in the transition limit and forgot to give ranges for L and c. Now it should be correct]

Here’s the formulas:

The ranges are:

  • for L: 0-2, these limits have to be.
  • for c: 1-10, these limit can be changed. Smaller than one doesn’t reach 0 and 1 anymore and 10 is already very steep.

And here’s an example plot:

4 Likes

Cripes, now I’m going to have to program something… :laughing:

Interesting! Two things: 1) Your conditional in the first figure should be, “For i < L …”; 2) in parameterizing this, how would you pull down the roll-off to the top on the right curve? (I’m too lazy to pick through the terms…)

2 Likes

Hi you are right, typo!

I haven’t thought about that. I just had the idea for the double logistic and searched for the right formula to connect the two.

What exaclty is the roll-off?
The slope of the final part in the top right?

Yes, the gradual rise to 1,1. This part of the curve tends to crush highlights, so increasing its slope would avoid that.

I’m thinking about incorporating this in my “tone curve zoo” in rawproc, with the same sort of parameterization as is done for filmic:

rawproc-tonecurve_pane

1 Like