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.
If you read the scrollback, you’ll find that I actually did have an implementation as a module in darktable but:
It doesn’t fit the darktable way of doing things at all, because it uses the entire image area so it kinda throws away a bunch of their region-of-interest optimization when you zoom in.
It operates in a very particular part of the pipeline since it takes in linear brightness RGB data in the output color space and outputs tone curved data.
Even regardless of those, while it technically did work, it didn’t look like Filmulator’s output and I couldn’t figure out why. I don’t know if the issue was the color handling or what.
I wouldn’t be dogfooding it, because I don’t use darktable.
I’d love to if I had the knowledge of how to do so. I think suggestions can be valuable to a development community. I’m sure it gets irritating when people come across as making demands instead of making a suggestion, but saying “wanting features is not very motivating to devs” discourages people from proposing ideas or giving support to ideas that could be worth a developer’s consideration.
