love the fact that this exists! 
I’m a fan of light edits, and pushing brightness up in RawTherapee does cause detail loss locally. I wonder what the status of a RawTherapee equivalent of this is; like do we have one?
Which OS and window manager are you using? Are you maybe using mutter?
This could be a good tool to add into librtprocess, once the analytical function used for the tone mapping is well tested and people are happy with it.
@heckflosse @CarVac what do you think?
1 Like
I mean we already have local contrast, which I make use of, but yeah improvement is always appreciated
I am still uncomfortable with the tm tools in PF and therefore don’t see them as suitable for librtprocess. There is also the point that different devs would want to approach the same problem differently. I don’t know: I am not a dev myself, nor a part of the librtprocess team. I actually see the OCIO stuff as a better candidate for integration; however, it is still early days with what is essentially looks without configuration.
Ubuntu 18.04 / Gnome / Wayland
I have reported this several times since floating windows have been a thing. The only way to close them is to press escape on Windows. I do get an X button but it is disabled. (Maybe I am missing something. I haven’t investigated the problem recently…)
That’s were I really need advice/feedback. I am trying to make the tool as simple as possible, yet flexible enough to provide a good output in all conditions. Do you find the DT filmic tool more intuitive?
I really need to get this sorted out! Wayland might be the issue on Linux, for in the windows case I have no clue…
Agreed about the once 
So this is a tone curve that replaces an sRGB tone curve?
Is this packaged with the detail separation or is that done separately in PhotoFlow?
Same here, this eases everything. Thanks for the tip.
1 Like
No, the sRGB tone curve is an encoding curve. It maps [0,1] to [0,1], but re-shuffles the bit allocation so that more bits are used to describe the dark tones, for which our eyes are more sensitive.
The tone mapping instead compresses the scene-referred values (which can easily exceed 1 where highlights are above diffuse white, or above 5x mid-grey) into the hardware display range of [0,1]. It therefore changes the appearance of the image, while the sRGB curve only helps avoiding banding effects at small bit depths, but does not otherwise change tonal distribution in the image.
It is combined, because the tone curve flattens the image in some tonal regions. Therefore I am offering the possibility to apply the tone mapping to a blurred image, and re-inject the local contrast at the end.
I will try to set LC_NUMERIC manually in the code when OCIO is enabled, as a workaround until the OCIO bug gets fixed…
More what I’m asking is: does this replace or augment some other tool in a pipeline you create with PhotoFlow? Or in another editor?
(In Filmulator this would involve ripping out the whole core of Filmulation, which has the same purpose of reducing dynamic range without destroying local contrast.)
That is precisely what I meant by my previous comment. Different devs approach the dynamic range and local contrast problem differently.
And partially why I was originally skeptical about incorporating other tools into the filmic tone mapper. Of course, I could ignore those parameters.
As filmic tm is currently, I don’t see it as general purpose, whereas the OCIO modules appear to be more viable since they act as another layer of abstraction on top or beneath the existing pipeline.
Once they are robust and configurable.
I’ve been messing with a filmic tone curve in rawproc, specifically the HP Duiker definition:
R(x) = x *(6.2* x+.5))/(x *(6.2* x+1.7)+0.06
Not at all parametric, but it gives me an idea of what it is supposed to do compared to some of the other scaling curves. On my test image with the locomotive headlamp, it does leave me with a decent amount of tonality in the lamp itself, while spreading out the lower data in a pleasing fashion.
This post, and others in this author’s blog, may be of help:
As you know I have been playing with filmic related ideas for a long time, I just don’t have the programming chops. Perhaps, it was the magic lantern ufraw-mod that got me thinking about this subject.
The good thing is that PF has been accumulating several filmic related tm tools, two of which are implementations of Filmic Worlds’ examples that @ggbutcher just linked. They are currently under Tone mapping old among others.
In fact, the latest TM curve I’ve been working on follows the same principle as the Filmic World’s one, but IMHO with more intuitive parameters…
All this curves, including the OCIO-filmic ones, are intended to be used as the very last step, to prepare the image for display. They serve the same purpose, but in more or less different ways.
1 Like
In order of preference:
- filmic (OCIO)
- filmic (tm)
- filmic (tm old)
- filmic new (tm old)
In some ways yes and in other ways no. I know what they are intuitively but I haven’t put my thoughts to words yet. I would say that dt’s filmic often gives me better results but the interface is trying too hard to be accessible, which has sort of backfired given the amount of posts about it.
PS It might be unfair to make a one-to-one comparison because it seemed that @anon41087856 was constrained by dt’s pipeline and workflow philosophy, which he is currently working hard to unravel and perhaps modernize.
PPS dt’s filmic and PF’s filmic (OCIO) are based on Troy’s work. If filmic (OCIO) is my #1 and dt’s filmic is in some ways better than #2, then it would be logical to say that I like the adaptations of Troy’s implementation more than the adaptations of Filmic World’s.
Today, I encountered a case where I couldn’t close a mask layer floating window. I could close the others but not that one. Also, I encountered a situation where PF was stuck at caching, eventually crashing. Let me qualify the word stuck by saying that the GUI was still operational. Unfortunately, I cannot reproduce either issues.
Both cases happened as I was editing my latest PlayRaw. Second case was when I started moving the module layers around and toggling them.