I don’t understand.
Either you define a threshold, apply a log below and a curve above, and it sucks to ensure continuity of the slope.
Or you apply the log, then the curve in log space, which is already what filmic does.
It’s my usual goal of a curve that is more flexible/easier to control than filmic. A null curve in filmic then stacked with a curve or any tool controlling global contrast in a separate module. Edit: The above is a bit confusing. Easiest way to conceptualise it is to see the curve part of filmic as a separate module, or the log part for that matter.
That’s how Photoflow, Art and RT does it but I’m not sure how similar the implementations are.
There’s the “tone curve” module in dt – is that what you’re thinking of?
Well, yes and no. My possibly very flawed understanding of filmic is that the modules does a lot of things. Two of the main things are log mapping and filmic tone curve. I feel, from using the other implementations, that the tone curve part of the filmic module isn’t as flexible as it could be. It produces great results when a number of assumptions are filled but once outside of these you have to fight against what the curve has done.
If you could turn off the filmic tone curve or if it was implemented as a separate module you could handle tones with any number of tools that suit your task but still have access to the log mapping and other features.
1 Like
But filmic is not a tone curve. Its task is to get input from a range [0;…] to a range [0;1], with a transformation to perceptual (log) space. But it most certainly was never intended to allow precise control over the exact shape of the curve, so it only has the 3 required points: black point, middle gray (which should be invariant), white point. Don’t try to make it do more than it’s intended to do (there are some refinements, but those don’t change the basic function of the module).
If you want a tone curve, there’s the tone equaliser module, or the tone curve module. Or there’s the exposure module with masking.
1 Like
I think nosle is asking log encoding plus the power curve for bringing midtones to 0.18
I can’t see how the filmic curve isn’t a tone curve but I’ll avoid the ‘tone’ word.
Imagine ditching the look tab and having it as a separate module. That’s it.
Wouldn’t it be cleaner to have the scene referred and the look separately. The look is look anyway and has to change for all outputs. I admit I don’t know that the look tab is the one locking certain things in but I think so.
Can’t you use a combination of filmic and tone curve?
If that is as straight as it looks that should do it. Will give it a go and see how it works. I failed to get it that straight when I tried last time. If that toe and shoulder has as little impact as it seems by the curve it should be fine.
Regardless, having it a separate module or just and option to disable it might be a good idea.
Well, it’s not very sensitive to the black relative exposure:
But you can break it with the white one:
You can then further reduce contrast:
My first tests are promising! Need to find a suitable high dynamic range playraw to test it against. In my first test the file felt super malleable. It’s a weird workaround messing with the scene settings like that and fiddly to achieve a straightish line but it does seem to work.
Separating the mapping of [0-inf] to [0-1] from the tone curve is something that seems desirable.
Filmic does many things in one.
If they can be separated, you could select whaterver you like.
I don’t know if it is possible to separate it as 3? steps: the curve providing the log correction (it is not the only way of doing that, so you could choose and test other options), the curve controlling contrast and the fight against out of gamut colors and clipped tones.
If it cannot be separated, may be it could be made “pluggable” in such a way that other implementations of each could be added with easy.
For me using modules that make only a single thing without afecting others is easier, you can concentrate in one task at a time and test the results easier.
Thank you for the clarification about basecurve and filmic.
You should try this method of straightening the curve. Perhaps heretically i just center the histogram with the scene settings and remove all contrast and latitude, perhaps some tweaks to make it more linear after that. I find it works really well! Using tone curve, tone eq, colourrgb to do the rest of the work.
I mean it’s to clunky to actually edit like that but it might help identify if it is the solution to our difficulties. I’m early in now but first experiments are good.
I whole heartedly understand your frustration with comments like:
Especially as you had to push hard to get it in and that it’s now kind of connected to you and your persona. I think everyone who has put their minds into the whys of doing it now understands that it was the right thing to do.
But I think comments like these:
deserves to be taken seriously and analysied with the mindset that it’s a symptom of something that can be fixed with a bit of work.
I mean the old hack of applying a base curve before the input profile had its perks and I would guess that people simply miss these perks. A couple I can think of:
- Clipped highlights
- Out of gamut colors
- Graphical vs parametric settings
- RGB ratio vs Per Channel display transform
The first one was super easy in the old workflow, just clip all channels at the level of the lowest shared maximum level. That worked for a surprisingly large amount of images. This does however not work anymore as we do not know what white is at this point. Proper methods are on their way now, but the answer has been “Don’t overexpose your image” for several years before that.
Gamut is another interesting thing. Applying a per-channel tone curve in camera space has the advantage of all data being strictly positive! The hack stopped many weird clamped colors from becoming a problem. This is still absolutely harder todo in the scene-referred workflow. Maybe that’s just how it has to be or maybe its possible to work more on.
Some likes graphs some likes parameters. The base curve will be your preference if you like graphs, nothing to judge here really. That said we could easily make the base curve module support an adjustable white point and appropriate view options that should make it as good of a curve candidate as filmic’s stricter setup. I can even sign up for making a try on this if the core devs thinks its a good idea.
That last topic is a hornet nest to unwrap. I think this is probably the number one reasons people disliked filmic over the years. They simply expected results more similar to the per-channel approach and obviously didn’t get it.
1 Like
Haven’t had time for playraws but I have to repeat that my results, after zeroing the filmic curve, look great, really great so far. Tone eq suddenly shines and the flat log output is better than the others I’ve tried.
I think you might be out on a hacky fragile path with these filmic + base curve tests.
log is not magic its just a different way of expressing math, the basics are essentially:
log(2x) = log(2) + log(x)
log(x^2) = 2 log(x)
You would probably be better of with a base curve with a adjustable white point.
The technical implementation might need some smart scaling (log or root) of the input data for reducing the needed size of the LUT table and still avoiding quantization problems.
There are however situations where doing operations in log space is awesome, examples:
- Exposure changes become easy additions
- Contrast control is a simple change of linear slope
- The combination is thus just a linear transform
in log space!
But again, no magic just a different way to do the needed math.
while I appreciate the thread … this is the wrong place for this. the information needs to be in the manual.
lets call the chapter “concepts of darktable - or why do we recommend this workflow”
1 Like
I think you’ve misunderstood? I do realize it’s much, much more likely I have misunderstood but. I’m just feeding the tone curve module a flatter image right, I’m not forcing it to do log math?!? Poor thing 
I sure hope I’m not because this workflow seems to solve the issues I’ve been harping on about for years now.
Huuuuh… What ?
Filmic maps scene to display subjected to look. How do you want to ditch that ? They come as a pack. Scene is the input range, display is the output range, look is what happens in the bounds.
Filmic v1 did only one thing. Stuff have been added over the years because it was not enough to fix all the problems happening at tone mapping. As problems appeared, options got added to fix them.
Separating them is not desirable. First of all, because the log is normalized to output stuff between 0; 1, and so is the curve. But where is middle-grey ? Inside filmic, we know it because we have a complete view over the mapping, so we can predict where middle grey will end. Split that, and you have no idea anymore. And ensuring middle-grey is passed-through is very important.
Then, splitting in 3 means multiplying I/O latency overhead by 3. In image processing, moving pixels across memories is much longer than the computations we typically do (except maybe for transcendental functions like atan, log, exp, sin, cos, etc.). Every new module needs to re-read the whole image from the top. Whereas cramming as much operation as possible within a single loop helps reducing runtime.
Each tab in filmic does only a single thing. At that point, it’s purely symbolic how you seperate functionality between modules.
2 Likes
If you haven’t yet give it a shot. Center the histogram using the scene tab, zero contrast and latitude, check that the curve is straightish.
Use the tone curve module to shape contrast in a tricky high dynamic range file. Touch up with tone eq and colour rgb. Use of the tricky underexposed city/landscape playraws. I couldn’t find them quicky enough so I used my own.
Great results very quickly. (I may be torturing a tone curve module in the backround but it’s worth it.)
1 Like