It may be a few days, need to work it around kitchen reorganization (this is a real kitchen, not the ‘kitchen sink’ that is rawproc… 
)
General means “as many variables as needed to model the phenomenon at hand”, specialized means “set useless variables to 1 or 0 to neutralize them and remove as many degrees of freedom as needed”. Nothing to do with Occam’s razor, but what do I know ?
2 Likes
In the general case, specialisation may bind variables to values other than 0 or 1, but you are certainly right that this process has nothing to do with Occam’s Razor 
1 Like
@McCap pretty pictures can certainly tug at my heartstrings. 
2 Likes
Had an idea for the roll-of.
Let’s call the logisitc functions given above LF (choose according to the value of L). Then just make:
o = (1-w) * LF + w * i
So you can transition between logisitc and linear. It’s just an idea I have plotted or tried it in any way yet.
It is really nice to see you making those observations! I’m seeing those well and it’s good to know I’m not the only one noticing how well the log-logistic curve behaves!
@McCap awesome idea! One question, did you first take the logarithm of the x-axis? That would indeed make it similar to the log-logistic curve. As for @ggbutcher comment on the highlight roll-off, I would say that it should converge to the white point as the logistic curve does. Modifications can instead be done on where the two pieces meet, shifting this point will have a similar effect as skewing a distribution and can therefore be used to define how hard the highlight approach should be! I will try to add it as soon as I have @McCap if you don’t mind!
About models, number of parameters and Occam’s razor. I’m fairly certain that the chemical process of negative film and paper prints is not a cubic spline in logspace but something else, so I wouldn’t call the filmic module the one truth but rather a good approximation of this system of chemical processes. Having the option to use a lower complexity model that covers most of the use-cases for most people seems like a pretty good idea in that light. Of course only as long as it fulfills some basic requirements such as customizable target white and target black etc.
3 Likes
I have a working but extremely slow python version (using opencv) ready and it works just fine, if anybody is interested
I have also included the the possibility to mix a linear function with the double logisitc as mentioned above to get a smoother transition in the highs and lows.
@janden, no I am not taking the log, because I want a “knee”. The function above maps 0…1 to 0…1. The L shifts the x point where the transition is and also scales both functions. The c is the steepness at the transition. So it’s basically two parameters.
Add to that the weight for the linear part as shown here:
And you have three parameters.
cheers
1 Like
So far I’d say all the curves you’ve thrown at it are reproducible, including the 1000nits ACES HLG curve. Sure, some minor deviations, but nothing offensive. I wonder for which curves, or display brightnesses it actually ‘breaks’?!
I’m asking myself the same question. I’m also the kind of engineer that searches for when things break and use that as a space for learning and improving. Working on skewness, pretty promising but a pain to get it right.
1 Like
Thanks for the feedback, I was indeed getting a discontinuity with that code organization. I went back to the original organization copied from the loggamma code, with a fix to accommodate < 0 values. The dual logistic algorithm was working correctly, it turns out, but the toe was too big for the linear data. Here’s the result; note the duallogistic parameters:
Only have experience with two sample images, but the toe seems to work generally at L=0.002 or so, and the c just rolls the brightness nicely between 1 and 10 just like you suggested. I think I’ll keep it, it’ll show up in the upcoming rawproc 1.1.
2 Likes
What I’m wondering about “duallogistic” (@McCap, if you have a better name for your creation, I’ll happily adopt it… ) is whether the 1-10 c setting could be tied to some aspect of the image, maybe some histogram statistic, that would facilitate an appropriate initial setting. Probably a fool’s errand, but, well, I’m a fool…
Good question?
My first thoughts would be tie L to the max of the histogram and c to the with. Now, this only works in a perfect world where histograms have only one peak and everything is smooth.
I call it double logistic, but it’s not copyrighted. 
1 Like
Updated the streamlit app with a first version of skew on the log-logistic curve and some additional view modes, most notably loglog.
The skew for the log-logistic curve is based on the Generalized Logistic Distribution Type I found here:
https://en.wikipedia.org/wiki/Generalized_logistic_distribution
But as a log-logistic version and forced to fulfill target luminances as well as crossing middle grey as a pivot. You will soon realize that it isn’t orthogonal so changing skew will change contrast as well. alpha = 5^skew for better scaling of slider precision.
Have a look!
Wow @McCap and @ggbutcher impressive implementation velocity!
1 Like
@McCap deserves the lion’s share of credit; a two-parameter filmic-like curve is in my mind quite elegant. Particularly, I believe it has potential for adjustment based on the image’s histogram, right now I’m thinking something along the lines of using the position of the tallest bucket to select a value for c between 1 and 10…
Right now, my batch tool chain has a filmic curve parameterized one way, and I usually have to reprocess a number of images whose exposure isn’t well supported with those parameters. I think doublelogistic may provide the potential to adapt the tone curve in-process.
3 Likes
Played around with it some more myself. Especially three things stand out to me:
- Look how nice bell shape with a flat plateau the ACES sRGB curve has when viewed in the LogLog view mode! And the log-logistic one follows almost perfectly! I guess this is the shape that is referred to when filmic is said to be “linear” in the mid-tones.
- Check out the blocky piecewise linear HLG curve when viewed in LogLog! This comes from the fact that this curve uses only one level of B-splines for interpolation. The sRGB output has two levels of B-splines which hide the interpolation method.
- It is nice to see how the skew parameter, in loglog view mode, really just skews the “hill” to the left or right but leaves the plateau straight.
Also, put in the work to add this double logistic curve as well to get a one to one comparison against the other methods discussed here. Please have a look. Some notes, it does not converge to zero and seems to always converge to 1 at around a scene intensity of two. But actually works better than I expected it to do taking into consideration that the logistic function is supposed to operate on a (-inf, inf) range and not [0, inf) range
2 Likes
Nice work, thanks for implementing the double-logistic!
The double logisitc has a “peak” on the hump which marks the transition point between the two curves.
I’ll have to play with that tool some more.
Thanks, for the nice words. I actually have considerably reduced the max c value while playing around. 10 is just too steep. Right now I play with values around 1 and 3.
3 Likes
Excellent! With the loglog view it becomes blatantly apparent how flexible and well behaved log-logistic+skew is.
Pro’s:
-
It can fit sRGB transfer curves from camera-manufacturers. It fits ACES sRGB 100nits curve. It fits ACES HLG 1000nits curve. It fits all seven of Troys piecewise cubic spline filmic curves. (minor deviations at continuity jumps) I wonder if it can fit 2000nits or 4000nits rendering intent HLG curves as well. Same goes for PQ curves with different rendering intents. Reminder: in loglog space ACES 1000nits is a 4-piece piecewise linear curve, and log-logistic+skew is able to fit it within reason.
-
None of the tweaks needed to fit take a long time. It behaves well without skewness, with skewness because of the non-orthogonality of the parameter it becomes a noticeably longer tweak (5s → 25s), but still…
-
adaptable to different output brightnesses without totally butchering your previous tweaks. Yes the contrast+skewness parameters have to be adjusted, but it’s funny how quick that works.
-
log-logistic+skewness does not produce over and undershoots, is smooth in the first derivative. I suspect because of that it should be more resilient to local-contrast artefacts in display-referred workflows (if one is inclined to make such horrible life choices
)
Con’s:
- Maybe tweaking two parameters of log-lopgistic+skew to maintain midtone contrast and achieving the right contrast for highlight and shadows could be improved upon, but it’s already possible in an either/or fashion. I’ve only played so long with the paramters. While maintaining midtone contrast, you can choose either shadows or highlights to be contrasty. Maybe the double-logistic is the solution for that so one can have both. I am curious.
Maybe in all of my subjective assessment I miss something. I am fully aware that filmic for example is going for a very specific look and process reproduction, which I think it achieves.
But if one claims filmic to be a ‘beautiful general framework’ with lots of control I’d like to see it replicate other curves for starters for that would be something that a general framework with lots of control would be able to do (without crushing blacks or producing over+undershoots).
Same goes for the futureproofing-of-darktable/HDR-argument: Well, log-logistic+skewness accomodates different display brightnesses with not much tweaking. 
Maybe it’s a bit obnoxious that I repeat myself: It’s a mystery to me how one can say that this is yet-another-basecurve when it clearly is not.
Cheers! I love you all! 
4 Likes
My two test images are c=2 and 3
Now, I tried an into-the-sun extreme DR image and couldn’t get close to what I did with the loggamma curve followed by a rather discontinuous control-point curve. I also wasn’t successful with flimic, so I think there are just some images that will still require special attention…
Yes! The LogLog plot was a surprisingly good addition to understand what happens with the curves!
As for the HLG and PQ ACES curves for brighter screens. The 4-piece piecewise linear curve seen in the 1000 nits HLG example is, as far as I can tell from the ACES source code, the RRT transform. It fits with the number of pieces and there is no curve like that in the ODTs for HLG and PQ. So the 2000-nits and 4000-nits render intents should look quite similar after inverting the non-linear quantization as I did for the HLG 1000 nits here.
About tweaking time, yes only contrast is super fast, introducing skew i.e. one more dimension seems to square the time. Not surprising really, making it truly orthogonal would of course reduce the needed time to something more like 5 + 5 instead of 5 * 5. Adapting the brightness is kind of related to this, changing the brightness should optimally not change the contrast of the picture. I think I know how to solve that one at least, so another item on the to-do list!
It is smooth in the higher-order derivatives as well
About your con, are you thinking about a possibility to tune the tail lengths? Something like what the latitude parameter in filmic tries to do? I’m not sure that would be doable without introducing some sort of piecewise approach, but that will most likely cause discontinuous higher-order derivatives and there is only so much a global tone mapper can do to an image. My gut feeling based on what I did on pictures at the beginning of this thread is that any editing need not covered by contrast and skew actually isn’t solvable with a global tone mapper but rather requires some sort of dodge and burn method such as the tone equalizer. I will let that be my assumption for now until we find some images where it seems like it would be needed.
And thank you for the comments!
2 Likes
Oh! I got it. I think for the whole story of scene-to-display you still need the ODT in addition to the RRT if I remember correctly. The RRT transforms to an ‘output referred’ space (not sure why this should not be linear-light actually), all look-decisions should be done before that transform and then there is the ODT which transforms output-referred to display-referred.
Probably. But also worth checking that assumption.
Making a 2D plot of contrast and skewness parameters could lead to sort of iso-midtone-contrast lines which a user could ‘walk along’ for changing shadow or highlight contrast. If I have time I could make a sketch if it’s not clear what I mean.
I think in fluid dynamics this is indicative of how long a laminar flow is attached to the surface. What I mean to say is that smooth-higher-order-derivatives is not a ‘crazy’ metric for assessing certain qualities. But I only assume that this is helpful for image editing, I don’t know.
kind of. Seems like a brute force approach to bolt on functionality. But sure this would make the smooth first order derivative go away.
Yes. Somewhere in this thread I said that there is a discussion to be had where certain decisions about a ‘look’ should be made in a pipeline, and where they shouldn’t. PQ and HLG workflows push certain decisions away from the ‘X-to-display’ mapping. ACES too, which introduces another transform in between. The question becomes if adjusting highlight-contrast/detail/structure/saturation/etc., NOT highlight mapping to peak display mapping, should be part of a ‘…-to-display’ mapping curve. Seems like an esoteric point, especially since no sRGB-display-referred workflow has to think about this as ‘anything goes’ there. In the color grading world there is a differentiation between ‘technical LUTs’ and ‘artistic LUTs’ (applies to funtions as well) for a reason.
I think BT.2390 is definitely a technical tool. Not sure where I would place log-logistic+skew. Filmic is for me, at the moment, more a specialized artistic tool.