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. 
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.
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.
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⊠
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:
1 Like
Ok.
Right now I am only using L and c as parameters and c does change the roll-off somewhat but is always connected to the steepness in the middle part. Iâll think about it some more.
And let me know when you have it incorporated, then Iâll test it. I have only played with the formulas so far and havenât tried it yet on images.