Filmic usability -- my usability "study"

[PhotoPhysicsGuy (Bob)]

@wpferguson

Some images don’t need filmic. I’ve had some images that didn’t need filmic or base curve, and applying either one just messed them up.

Cool, so when talking about filmic and its usability, or when trying to understand what users problems with filmic are, we can exclude those from the discussion. Would you agree on that? That of course also includes telling the user that they might want to use some other module depending on the content.

@wpferguson

Filmic can be adjusted to handle badly exposed images and base curve couldn’t.

Here we are talking about correctly exposed hills and a very bright sky/clouds which may or may not be blown out (raw channel clipping).

@pass712

Clipped highlights aren’t really handled by filmic alone.

well, even non-clipped highlights are only to a certain degree. I’ll try to explain further below.

@rvietor

Landscapes can have rather large dynamic ranges, so you probably will have to adjust filmic to compensate for that.

So there needs to be at least one (or more) module(s) that specifically deals with dynamic range mapping. Filmic is designed to do that. Well it’s also designed to do a bit more, it also gives a certain look to the result → logarithmic mapping of scene to display, parametrically adjustable with desaturation of highlights and shadows to taste.

@s7habo

This is in fact already the “first” step towards adapting to the human visual experience.

Well, this is already what many people would describe as a tone mapper, your third point.
It’s very interesting that you put tonemapping as your last/final point.

@s7habo

LUT are unsuitable for this, because they are hard-coded values, which can be changed only partially afterwards

I’m not advocating for LUTs, don’t get me wrong. I’m more asking for the benefits of a parametrically adjustable tone- and gamut-mapping curve if all the advice regarding some usability-…err…hickups is, I’m paraphrasing “don’t touch the parameters!”. If people make/suggest luminance masks for a second instance of an exposure module before filmic, what they are effectively doing/suggesting is what a highlight-parameter-control inside of a tonemapping module could be doing, it’s not the same though! There is what I would call the scene-referred “reference image” and the tonemapped display-referred output. At least in an ACES-like pipeline concept. Not sure what darktables pipeline concept entails.

There seem to be different qualities of advice. This is especially problematic because depending on which thread about filmic you read, it is lauded for the control that it can exert, how futureproof it is, etc… But the different advice don’t seem to reflect that.

I think those very mixed messages need to be adressed in conjunction with what other people have contributed for future versions. Controlling (or wanting to control) the amount of tonemapping in a scene-to-display-mapping module IS something different than what ToneEQ (or exposure module instances and the like) does.

ToneEQ et. al. affect(s) the “reference image” which is scene-referred. Filmic affects the display-referred rendering of that reference image.
Tweaking Filmic is thus necessary when you have/want/need several different outputs like print/sRGB/AdobeRGB/ProPhoto/HDR. All of those display-referred formats/color-spaces need a different scene-to-display tone- and gamut-mapping. And in principle the output renderings could be handled by LUTs relegating the tweaking into scene referred space. I’m not saying that this is a good idea! I’m advocating for the parametric approach like in filmic, but for that there needs to be concise-control in the module AND communication about the issue(s). And there are Issues.

The answers “It’s a starting point”,“tweak in other modules!”, “don’t iteratively tweak!” feel like they are skirting the very specific usability challenges of filmic. And I wholeheartedly agree that those answers are also not wrong at all! This makes the discussion so nuanced.

I’m sure future iterations will mitigate some challenges the users have with filmic. I also feel that the knowledge what the darktable pipeline is and where to adjust what and where not to is at least as important.

Sorry for rambling.

[s7habo (Boris Hajdukovic)]

@PhotoPhysicsGuy

I think those very mixed messages need to be adressed in conjunction with what other people have contributed for future versions. Controlling (or wanting to control) the amount of tonemapping in a scene-to-display-mapping module IS something different than what ToneEQ (or exposure module instances and the like) does.

ToneEQ et. al. affect(s) the “reference image” which is scene-referred. Filmic affects the display-referred rendering of that reference image.
Tweaking Filmic is thus necessary when you have/want/need several different outputs like print/sRGB/AdobeRGB/ProPhoto/HDR. All of those display-referred formats/color-spaces need a different scene-to-display tone- and gamut-mapping. And in principle the output renderings could be handled by LUTs relegating the tweaking into scene referred space. I’m not saying that this is a good idea! I’m advocating for the parametric approach like in filmic, but for that there needs to be concise-control in the module AND communication about the issue(s). And there are Issues.

Ok, now that we’ve cleared that up, what would be your recommendation on how to handle it while we wait for a more reasonable practical solution from you?

Do you think we should not use the darktable until this solution is available, because at this time it is not possible to work with it, because the possible recommendations how to use it under these circumstances only cause confusion?

[paperdigits (Mica)]

@PhotoPhysicsGuy

here seem to be different qualities of advice. This is especially problematic because depending on which thread about filmic you read, it is lauded for the control that it can exert, how futureproof it is, etc… But the different advice don’t seem to reflect that.

This is why we tell people to start with the documentation, @anon41087856’s videos, etc.

If you think you’re going yo read random people’s advice on the internet and get it right without reading the authorative source, I don’t know how to help you.

It is clear from @Mister_Teatime’s video that they hasn’t come anywhere near the docs, as several of his random quibbles are addressed in the docs, and some are even what he wants, but hasn’t figured out the options are there.

[wpferguson (Bill Ferguson)]

@PhotoPhysicsGuy

I think those very mixed messages need to be adressed in conjunction with what other people have contributed for future versions. Controlling (or wanting to control) the amount of tonemapping in a scene-to-display-mapping module IS something different than what ToneEQ (or exposure module instances and the like) does.

If you asked how do you use the color balance module, you would probably get a similar array of conflicting information. Different people use filmic in different ways, according to how they see an image and what they want to do to it. You seem to be looking for the single, definitive, correct way to use filmic and that doesn’t exist. Any more than a single, definitive, correct way to edit an image.

[priort (Todd Prior)]

In the ACES schema would filmic in DT be doing the equivalent of the LMT and RRT??
LUTs vs Transforms: How They're Different and Why It Matters.
If so how could you expect not to have to tweak it to achieve the optimal result…maybe its surprising you don’t have to tweak it more…

[jandren (Jakob Andrén)]

It’s always nice to pick up pictures from others and try your editing skills on!
Here is my attempt using the latest Sigmoid branch that I’m slowly progressing on.

_MG_0653.CR2.xmp (45.8 KB)

It needed some fiddling back and forth with the sigmoid contrast and skew parameters as I haven’t implemented good orthogonality between them yet. But not too much really and the majority of the work is performed in other modules anyway, and that should be the case when using the filmic module as well.

Note that I try to stay scene-referred in my edit, i.e. no modules above the display mapping (read filmic or in my case sigmoid). The only module that I prefer in display-referred space is the wonderful color zones module. That one really needs a scene-referred sibling!

I basically wanted the blown-out highlights to go fully white as the highlight reconstruction isn’t very good in darktable atm and I believe it should be bright as that is where the sun is. I then used a combination of masked exposure modules and the tone equalizer to lift (dodge) the grass and bring down (burn) the clouds to my liking. A bit of local contrast as icing on the top.

As for this usability thing of filmic. My personal feeling is that exposes a lot more control than it can give. It thus gives a false impression on what it actually can do (read: a masked exposure can take you very far) as well as being a bit inefficient to work with. You usually need to change multiple covariant settings for changing one single effect especially if you try to pay attention to the validity of the curve.

[jandren (Jakob Andrén)]

I believe the filmic equivalent in ACES would be the RRT*+ODT**. Which ODT depends on the target display. So yeah they have a fixed definition for that processing step in the ACES pipeline. The important thing to note is that it is illegal to put anything after (above) filmic as anything coming after (above) is a display referred edit.

.* RRT = Reference Rendering Transform, derived from a Fujifilm analog film and how it would look displayed on a perfect 10000 nits display.

** ODT = Output Device Transform, standardized method for viewing the same content on a display with lower dynamic range.

[s7habo (Boris Hajdukovic)]

@Mister_Teatime

So, do you simply use filmic like a fixed base curve, then?

Is the answer to my question about tweaking filmic settings “don’t tweak them, compensate with other tools”?

I would say tweak the “scene” part. Do not lose too much time in “look” part. Contrasts can also be treated in other ways.

[priort (Todd Prior)]

Okay I was one step early in the diagram in the link above , so likely then the DT output profile goes from the display to what ever the desired output colorspace is for export??..Likely if I go back to earlier filmic docs/vids Aurelien has explained the relationship of filmic and ACES I think I recall some discussion about it…

[PhotoPhysicsGuy (Bob)]

@s7habo

…while we wait for a more reasonable practical solution from you?

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.

@s7habo

Do you think we should not use the darktable until this solution is available, because at this time it is not possible to work with it, because the possible recommendations how to use it under these circumstances only cause confusion?

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.

@paperdigits

It is clear from @Mister_Teatime’s video that they hasn’t come anywhere near the docs, as several of his random quibbles are addressed in the docs, and some are even what he wants, but hasn’t figured out the options are there.

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.

@wpferguson

You seem to be looking for the single, definitive, correct way to use filmic and that doesn’t exist. Any more than a single, definitive, correct way to edit an image.

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.

[paperdigits (Mica)]

@PhotoPhysicsGuy

@paperdigits

It is clear from @Mister_Teatime’s video that they hasn’t come anywhere near the docs, as several of his random quibbles are addressed in the docs, and some are even what he wants, but hasn’t figured out the options are there.

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.

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.

[elstoc (Chris E)]

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.

[wpferguson (Bill Ferguson)]

@PhotoPhysicsGuy

I don’t know where I gave off that impression.

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.

[rvietor]

@PhotoPhysicsGuy

@rvietor

Landscapes can have rather large dynamic ranges, so you probably will have to adjust filmic to compensate for that.

So there needs to be at least one (or more) module(s) that specifically deals with dynamic range mapping. Filmic is designed to do that. Well it’s also designed to do a bit more, it also gives a certain look to the result → logarithmic mapping of scene to display, parametrically adjustable with desaturation of highlights and shadows to taste.

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.

[Jose_Figueres (jofial)]

my humble contribution

_MG_0653.CR2.xmp (23.8 KB)

[Dinobe]

My take.

_MG_0653_04.CR2.xmp (16.4 KB)

[priort (Todd Prior)]

What a novel concept

[afre (Alan)]

Super quick take; so yes, haloing along the edges of the mountains.

---

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.

[pass712]

@jandren

As for this usability thing of filmic. My personal feeling is that exposes a lot more control than it can give. It thus gives a false impression on what it actually can do (read: a masked exposure can take you very far) as well as being a bit inefficient to work with.

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

[PhotoPhysicsGuy (Bob)]

@wpferguson

you tell them why it doesn’t work for you.

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.

@wpferguson

All of the answers above, that you see as conflicting, are valid because that’s how people use filmic.

@PhotoPhysicsGuy

And I wholeheartedly agree that those answers are also not wrong at all! This makes the discussion so nuanced.

I stated the same thing.

@paperdigits

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.

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.