Thanks for the explanations. Makes perfect sense with the brightness limit. I just wonder what would be the best way to recover brightness after filmulation, since there are so many possibilities, not only the curves but levels etc.
With the slider loupes I had the same impression, they are not needed for filmulator. I wonder if it is possible to use the slider widget without the loupe. What would be missing then is a possibility to directly type in a value. However, I had a closer look and it is not that the slider loupes don’t work at all but it seems that the mapping of ranges of the loupe and the overall slider range is somehow weird.
Anyway, thanks for bringing filmulation to darktable! It’s a very interesting approach.
@CarVac Meanwhile I’ve quite significantly progressed in the inclusion of Filmulator into PhotoFlow.
However, before I can release an experimental version I need to clarify a couple of details:
how should I modify the parameters for a scaled-down version of the input image?
what is the minimum input region size which is needed to correctly process an output region of WxH+X+Y (where W and H are the region dimensions and X,Y are the offset)?
By the way, the filmulptor code is included in an experimental photoflow version that allows unbounded corrections of the exposure, so the brightness limitations mentioned above for darktable are not present…
The algorithm is scalable: you can resize the input image (keeping the aspect ratio, of course) and the output will be the same.
However, whatever the resolution you provide to it, it needs the entire image. Otherwise, the brightness is going to change dramatically depending on where you look: if the viewport only covers a dark area, it will be lighter than expected, and if the viewport covers only a light area, it will be darker than expected.
Regarding brightness: tools coming after it in the pipeline must realize that it’s not linear anymore. You can still try to apply the sRGB gamma at the end, but it won’t match the Filmulator output, which has a different curve instead of a standard gamma.
One approach to better match Filmulator would be to follow the filmulation with black point and white point controls, then apply that curve (a quadratic bezier curve from 0,0 to 0.2,1 to 1,1) and then undo the sRGB gamma, and treat that as roughly linear.
Is the PhotoFlow pipeline RGB? Lab? If RGB, what primaries, or is that selectable?
Actually, it can be whatever you want, depending on the chosen output colorspace of the RAW processing step. By default, I’m using linear Rec.2020, but the user is free to select both the primaries (currently I have built-in primaries for sRGB, Rec.2020 and ACES) and the tone response curve independently (so that one can for example use a Rec.2020 colorspace with the L* encoding).
One can also directly output Lab values from the RAW processor, but that’s not useful here.
I need to think how I can efficiently incorporate a filter that requires the whole image data into memory, because this is not straightforward in the current processing scheme.
How do you like what it can do in darktable? Any good results, or just trying it out?
Whenever I’m using it in darktable I’m constantly comparing it against what I expect from Filmulator and that strongly guides my processing tendencies, I’d like to see someone else’s interpretations of its capabilities.
Now that darktable has also moved to an RGB pipeline, would it make sense to resurrect this idea?
I know we have filmic, but filmulator often produces well-retained contrast, saturated but not over-saturated colours, and natural-looking highlights with out-of-the-box settings, which take me the combination of several modules with filmic et al.
I’d still prefer having a slow tool that I can choose not to use over having it not available at all. The stand-alone Filmulator, on its own, has OK performance (especially if I take it into account that I only have to use one tool instead of multiple). But I do miss darktable’s tools there (e.g. denoising, arbitrary rotation etc.)
i think we mainly didn’t pursue this idea to integrate filmulator into dt because of performance issues. requiring the whole image is not something that helps matters in dt’s pipeline. that said, i have (dysfunctional) code that runs the complexity of the filmulator inner workings on gpu for the full image. iirc it took like 20ms to run on a full image. that was probably 16–24 megapixels, i forget. this means there is probably hope to make this very fast indeed if we spend a bit of work on it. i’m really motivated to look into this, i think there are also still very interesting effects to be simulated between silver halide grains and developer.
After using Filmulator on my Mac for a few days (paid someone to build it for me, will make the build available soon) I would prefer to see the Filmulator ‘magic’ integrated in darktable.
I agree. Filmulator has a nice effect, but it is very much a “one-trick pony” (likely either by design or out of lack of available time for the developer to expand the program). It is lacking in a lot of features, for example: denoising , has no support for ICC profiles, doesn’t work with TIFFs, and doesn’t like raw files an old Sony camera I like to use with an RGBE sensor. While that last point will be of concern to verryyyy few people, if the same applies to other cameras with non-traditional sensors then they would also not be able to use filmulator. The filmulator algorithm itself is pretty nice, so I’d love to see it integrated with something like darktable or rawtherapee.
I’m definitely looking into supporting ICC Profiles next (especially because matrix profiles are hideously bad for the now-ubiquitous color LEDs), and… I’m not going to support RGBE, because it would break my current white balance pipeline which involves inverting the raw->xyz matrix, which can’t be done for 4-color CFAs.
It’s a very interesting approach.