I’m sorry that I apparently frustrated you with something I wrote. It wasn’t my intention.
Explaining the concepts of Filmic is the only answer I have at the moment. Asking the user things he might not know about his workflow in order to help him understand the concequences. I did explain what to expect from the Filmic controls in your very helpful thread.
Well it’s a rolled out module in version 4, probably not. At the same time: “don’t iteratively tweak”, “use a module before”, “use a module after” is basically relegating the user to use Filmic in a LUT-like fashion. So in my very humble opinion this is somewhat a Catch22.
We wouldn’t be having this conversation if @Mister_Teatime was the only person to face those issues. The fact that there is so many threads and questions about Filmic and how to use it points to an underlying conceptual issue. That is: users don’t know when and how to use it and what to expect from the module and it’s actual purpose. It’s not just a gamut-mapper, it’s not just a tone-mapper, it creates a very specific look with quite a bit of parameter-crosstalk at the connection between scene-referred and display-referred space.
I’m very uncomfortable with the advice “don’t touch it then!” when other modules like @jandren s Sigmoid or the bt.2390-tonemapping get shot down with the argument “you need the parameters in the module to be plenty, rich and futureproof” when they do similar things as Filmic does now, some of them more flexible/elegant than filmic. The advice given to users here does not match the arguments brought forth against other modules.
I don’t know where I gave off that impression. No, I am not looking for the one way to use it. I see a certain incongruency between actual recommended module-usage and the design-goal of the module. I believe that with the next iteration of the module this will mostly go away. Until then, the advice given might lead to more confusion and in turn to more frustration with developers.
My advice to @Mister_Teatime and probably a lot of others is: make sure to understand the difference between scene-referred and display-referred space and where a certain edit of yours should reside in. Depending on this decision you should choose tools appropriately.
Should an edit ripple through to all future versions? Stay in scene-referred with that edit!
Is an edit specific to a specific display? You’re welcome to let that edit reside in display referred space.
Filmic connects scene and display referred space, certain look-decisions could in theory thus adapt to different output formats. If you do not need this future-proofing or very specific adaptability because you happily reedit a picture when HDR arrives on linux for example, you can very well choose a different approach like LUTs or linear mapping or even deprecated base-curve. While tweaking highlight recovery can be done with Filmic, don’t expect it to work like in other software.
Also: iterative tweaks of filmic only make sense if you need or expect it’s specific funtionality to remain with future edits and versions of the same file. So if you count on that, thats the bitter pill to swallow.
: of course you can do whatever you want wherever you want. Whatever floats your boat.
Did you watch their video? This specific comment isn’t about filmic, but is about the 1/3 of the posted video that talks about non-filmic issues.
There are many gripes put further in the video, none of them at all related to filmic, that are answered in the docs.
Can you please read the docs? We write things down because there are only a few of us trying to serve a lot of users. Answering queations that are covered in the docs (and these questions aren’t even difficult ones like filmic) is a real strain on resources, which again, are thin to begin with. So please understans my extreme irritation with people not reading the docs, then complaining about a thing that is covered in the docs while starting their critique by stating that they can’t be assed to read the docs.
The other big advantage of reading the docs is that when you don’t understand something you can quote the docs and say “this isn’t clear”. We can then use that information to make the documentation better for the next person who has the same issues. This means that people don’t have to trawl through long pixls topics to find useful information, and you can both learn and contribute at the same time.
Because every time some one makes a suggestion you tell them why it doesn’t work for you. And so far, no one has been able to come up with an answer to satisfy you. All of the answers above, that you see as conflicting, are valid because that’s how people use filmic.
Go watch Aurelien’s video’s about filmic and use it the way he says.
As does one of the alternatoves: basecurve. From lwhat I understood, those curves actually aim to approach the in-camera rendering.
Also, the part of my post that you quoted was taken a bit out of context, which was a reply to @pass712 about crooectly exposed images not needing filmic adjustments.
Please don’t use my posts to further your agenda. If you take things out of context, of course you can make it appear as if the advice is contradictory.
PS If I were to spend more than 5s on the image, I would make 2 quality (halo-free) masks: one for the sky and the other the ground and use a different workflow for each.
E.g., high filmic contrast on the former and low on the latter as to normalize the contrast ratios between the two (within reason). There will be exposure or brightness adjustments too.
The reason for this line of thinking is that the distant mountains tend to not only have a haze but have similar characteristics as the sky. Separating the workflow will help you differentiate them a bit more and prevent the muddy appearance that dynamic compression or over-masking can cause.
Brings it to the point imho. Not to criticize what was developed here. Realizing a tonemapper with an easy to use and understand interface is no simple task. And the results shown here and in the PlayRaw speak for themselves. They improved a lot compared to those done with earlier versions of dt. The whole work done on the pipeline an the colourmanagement also lifted dt to another league.
Maybe a reduction to just the essential sliders could help. These could be: white and black relative exposure, middle tones saturation and the preserve chrominance menu.
Others like latitude and preserve chrominance could also be tweaked by a (non overshooting) curve-tool. If that’s what your module does I am very excited - looks very promising
I’m truly sorry to cause such a fuzz! I know how it works! Additionally I try to find out why so many users still have problems. User stories like this are the only way to find out why users seemingly do not read the docs.
I stated the same thing.
I understand the extreme irritation. I thought that by discussing the complex issues and how users act and interact with this forum and the software, we could improve this.
Okay, a bit off kilter, but I just logged into my work laptop and was presented with a login image that looks a lot like the image we’ve been messing with here…
I’ve been shooting photos of same patterns lately and I wouldn’t be able to do without being able to crank up the contrast and latitude to get the contrast into the images; they’re extremely flat.
Just because a slider is there doesn’t mean you have to move it. For a lot of photos, just black and white relative exposure is enough.
I would go even further and say: almost every image that went through filmic needs cranking up contrast. Or, as the manual says: “filmic rgb tends tends to compress local contrast, so after you have set up filmic rgb you may want to compensate for this using the local contrast module. You may also want to increase the saturation in the color balance module, and maybe further adjusts the tones using tone equalizer.”
So there are many other ways to achieve a better contrast. Out of a good reason: in most use cases contrast in filmic simply isn’t enough to deliver the right amount of punch. Just check the examples in this thread.
Or, as Jandren stated:
Your next point was:
Agreed. So why not let those additional sliders stay were they are to be used by more advanced users ? The essential sliders could be sampled on a “beginners” tab on the left.
The “quick access panel” of version 3.5.0 is a step in this direction and proves that some sort of slim down makes sence (also for other modules ).
Why not start a new topic and ask people? Or, since you already have ideas about how the usability can be enhanced start a topic about that where you and other people that think filmic can be/needs enhanced can all get together and hash it out. Once you have defined issues and possible solutions, then you can submit issues or PR’s to darktable for inclusion.
This thread started out as “how are you using filmic” but now it’s been hijacked into discussing filmic usability. Start a separate topic.
Speaking only as a user, I will say that my general approach is to adjust white balance and exposure for my subject and then adjust the white and black relative exposure sliders until I have the dynamic range under control. After that I’ll use increase the dynamic range scaling slider to accommodate local contrast and then I’m off to make make creative changes with tone, color, sharpness, etc. I rarely have a need to touch anything else within Filmic and I usually don’t have to go back to it. I might have to adjust contrast and latitude if I have an extreme scenario.
I’ve often wondered if I’m missing something because I don’t seem to have the issues others have had, but I’ve found these steps are all that’s necessary. At times I’ll have issues with desaturation where I don’t want it or out of gamut conditions with extreme blues, but I know to look for these and have learned to deal with them.
Any rate, here’s my take on your photo. I really like the rugged hillside and turbulent sky. Filmic took me less then a minute, about five minutes to pull out the cloud detail and another 20 minutes having fun with creative edits.
reside in. Depending on this decision you should choose tools appropriately.
).